Kontynuacja treści o warstwie dostępu do danych. Dzisiaj powiem o Data Access Objects i jak mają się one do omówionych wcześniej repozytoriów. Wspomnę o różnych podejściach przy pobieraniu danych i odpowiem na pytanie czy w ogóle potrzebujemy DAO.
W dzisiejszym wpisie wkraczamy do warstwy dostępu do danych i przy tej okazji omówię znany i lubiany wzorzec projektowy: Repository. O tym, czym jest repozytorium, jak powinno wyglądać i czym tak naprawdę powinno się zajmować.
Jeżeli masz dość if-ologii w swoim kodzie, to konieczne sprawdź czym jest czynnościowy wzorzec projektowy strategia. Pozwala on mądrze obsługiwać różne scenariusze w procesie i jednocześnie być fancy pod względem zasad SOLID.
SOLID (Single responsibility principle, Open/closed principle, Liskov substitution principle, Interface segregation principle, Dependency inversion principle), czyli pięć zasad programowania obiektowego, które każdy powinien przestrzegać.
Omawiam dzisiaj mało znaną zasadę, której stosowanie skutkuje posiadaniem łatwo utrzymywalnego i testowalnego kodu. Mowa o prawie demeter, które w najprostszym ujęciu zakłada, że obiekty powinny operować jedynie na najbliższym im otoczeniu.