1. Single Responsiblity Priciple (Zasada jednej odpowiedzialności )
1.1. S
1.2. Klasa powinna mieć pojedynczy powód do zmiany
1.2.1. Jeśli jest więcej takich powodów powinniśmy przenieść funkcjonalności do kolejnych klas
1.2.2. Klasa musi mieć więc pojedynczą odpowiedzialność, aby wymagała zmian w tylko jednym konkretnym przypadku.
1.3. przykład
1.3.1. jeśli chcesz w klasie tworzyć obiekty, to już jest odpowiedzialność
1.3.1.1. i od tego jest wzorzec fabryka
1.3.2. Wyobraźmy sobie klasę reprezentującą fakturę. Faktura ma pewną strukturę oraz pewien format wydruku. Może się zmienić dopuszczalna struktura faktury, dodatkowo może zmienić się format wydruku faktury. Widać więc, że tak zamodelowany obiekt ma dwa powody do zmiany, powinien zostać on więc rozłożony na dwie niezależne klasy
1.4. zastosowanie
1.4.1. architektura wysokiego poziomu
1.4.2. tworzenie "aktorów"
1.5. najważniejsza zasada
1.6. Command-query separation
1.6.1. to samo tylko dla metod
1.7. klasa X nie powinna zależeć od jakiejkolwiek implemencji klasy Y
1.8. metody klasy
1.8.1. powinny być ze sobą skolerowane
1.8.2. nie powinny się odwoływać do zewnętrznych obiektów ( w miarę możliwości )
1.9. wysoka spójność klasy
1.9.1. dobrze się czyta i używa ponownie
1.9.2. dobra do testowania
2. Open-Close Principle ( zasada otwarte-zamknięte )
2.1. O
2.2. Klasy powinny być otwarte na zmiany i zamknięte na modyfikacje.
2.2.1. Programista powinien więc tworzyć abstrakcyjne klasy, a konkretne zachowania umieszczać w klasach konkretnych
2.2.2. Pisząc klasę programista musi to robić w taki sposób, aby dodając kolejne funkcje nie musiał jej w przyszłości przebudowywać, a jedynie rozszerzać.
2.2.3. Ta sama zasada dotyczy bibliotek, modułów.
2.3. zastosowanie
2.3.1. projekowanie klas
2.3.2. rozszerzanie funkcjonalności
2.4. Dominująca straregia w OOP
2.5. przykład
2.5.1. obie klasy dobre,z tym że pierwsza nie jest otwarta na rozszerzenia
2.6. modularyzacja
2.6.1. w idealnym przypadku klasy powinny być zaprojektowane tak zmiana wewnątrz klasy ( nie zmieniając jej interfejsu) nie wymagała zmian w innych klasach
3. Liskov Substitution Principle - (Zasada podstawienia Liskov )
3.1. L
3.2. Typ bazowy powinien być zastępowalny w pełni przez typ pochodny.
3.3. przykład
3.3.1. kwadrat jest w "rzeczywistości" prostokątem, ale tutaj w kontekście pewnego zbioru odpowiedzialności funkcji to się nie sprawdza
3.4. zasada ta jest często łamana
3.5. zastosowanie
3.5.1. dziedziczenie
3.5.2. typowanie
3.6. programista nie powinien używać dziedziczenia nie wszystkie metody w klasie pochodnej mają sens funkcjonalny
4. Interface Segregation Principle - ( zasada segregacji interfejsów)
4.1. I
4.2. Programista nie powien pisać metod w tworzonym interfejsie, których nie potrzebuje
4.2.1. nadmiarowe metody trzeb zaimplementować !
4.2.2. interfejs powinien być dopasowany do rzeczywistej funkcjonalności
4.2.3. dobre interfejsy powinny być odpowiedzialne za jak najmniejszą funkcjonalność
4.3. przykład
4.4. zastosowanie
4.4.1. logika biznesowa
4.4.2. komunikacja z klientami
4.5. zły interfejs
4.5.1. fat
4.5.2. polutted
4.6. dobry interfejs
4.6.1. ukrywamy implementację
4.6.2. definiujemy podział projektu na składniki
4.6.3. dobrze zdefiniowany interfejs pozwala na pracę w wielu zespołach informatycznych
4.6.4. daję możliwość wykrycia błędów zanim zostanie zaimplementowanty
5. Dependency Inversion Principle - ( zasada odwrócenia zależności )
5.1. D
5.2. Powinno się operować na interfejsach oraz klasach abstrakcyjnych, a nie klasach kontkretnych.
5.2.1. Kod z warstw z wyższego poziomu nie powinien zależeć od kodu z niższych warstw. Obie warstwy za to powinny być zależne od abstrakcj
5.2.2. Abstrakcje nie powinny zależeć od szczegółów (konkretnej implementacji). Z kolei szczegóły (implementacja) powinna zależeć od abstrakcji.
5.3. zastosowanie
5.3.1. kod z wyższego poziomu (abstrakcja)
5.3.1.1. klasa abstrakcyjna
5.3.1.2. interfejs
5.3.2. kod z niższego poziomu
5.3.2.1. klasa konkretna
5.4. przykład
5.4.1. W żadnej definicji funkcji i w żadnej deklaracji zmiennej nie powinniśmy używać nazwy klasy, tylko nazw interfejsów lub klas abstrakcyjnych