Wątek na podstawie tematu Jak precyzyjnie zdefiniować pojedynczą odpowiedzialność w kontekście zasady SRP z S.O.L.I.D
Powiem szczerze że o ile zasada pojedyńczej odpowiedzialności jest nieco trudna do zrozumiania, to nie widze problemow związanych z innymi literkami.
Czyli po kolei:
- Single Responsibility Principle - jak pisałem, najtrudniejsza część SOLID i sam mam problemy żeby wiedziec czy kod spełnia tą zasadę
- Open/Closed Principle
- Liskov Substition Principle
- Interface Segregation Principle
- Dependency inversion principle
Open/Closed rozumiem w ten sposób, że jeśli na przykład mamy odtwarzacz muzyczny, i mamy komponent odpowiedzialny za wczytanie muzycznych metadanych z plików, to jeśli chcemy dodać obsługę nowego formatu np. WAV oprócz istniejących , to powinniśmy to zrobić tak by nie naruszać kodu odpowiedzialnego za pozostałe formaty. W OOP głównie stosuje się od tego interfejsy i polimorfizm, czyli w takiej Javie mielibyśmy AudioFileMetadataProvider i klasy typu Mp3AudioFileMetadataProvider
Liskov Substition Principle - oznacza to że podczas implementacji poliormizmu powinniśmy zastosować się do określonego kontraktu.Przykładowo jeśli jest Comparator<T> z metodą
int compare(T o1, T o2)
i powinna ona zwrócić ujemną liczbę, zero, lub liczbę dodadnią jeśli odpowiednio t1<t2/t1==t2/t1>t2 to implementacje powinniśmy tak napisac żeby przestrzegrać tej reguły.
Co do ISP i DIP myślę że to prostsze niż pierwsze 3 litery. Dodatkowo sądzę że zasady z SOLID też przynajmniej częściowo pasują do FP - tam sa funkcje wyższego rzędu czy polimorfizm, tylko że oparty na czyms nieco innym
O jawnym łamaniu LSP przez klasy sealed nawet nie wspominam.
@piotrpo: co masz na myśli?