Cezary Sanecki

Trzecia już zasada mnemoniku SOLID. Nazwa tej reguły pochodzi od nazwiska twórczyni, czyli Barbary Liskov. Według niej w miejscu, gdzie wykorzystywana jest klasa bazowa bez problemu można użyć klas pochodnych, które mogą rozszerzać bazowe funkcjonalności, ale zmiany w nich zawarte nie mogą mieć wpływu na działanie programu oraz jego wynik.... [Czytaj dalej]

Druga zasada mnemoniku SOLID. Praktyka mówiąca, że klasy powinny być otwarte na rozszerzenia, ale zamknięte na modyfikacje. Opracował ją Bertrand Meyer w 1988 r. Według niej dana encja powinna mieć możliwość zmiany swojego zachowania bez ingerowania w kod źródłowy. W ten sposób wytwarzamy system, który potrafi dostosować się do zmiennych... [Czytaj dalej]

Pierwsza zasada mnemoniku SOLID. Zgodnie z tą praktyką klasa powinna mieć tylko jedną odpowiedzialność. Musi istnieć jeden powód do jej zmiany. Dzięki temu łatwiej jest nam zrozumieć cel danej klasy, czyli jakie jest jej główne zadanie. Właśnie takie słowa wypowiedział znany nam wszystkim Uncle Bob: [Czytaj dalej]

W obiektowym podejściu do rozwijania oprogramowania warto kierować się zasadą SOLID. Praktyki w niej zawarte zostały zebrane przez sławnego Uncle Bob’a (Robert C. Martin), a Michael Feathers stworzył do tego piękny mnemonik. Dzięki tej grze słów (solid - solidny, mocny) akronim zyskał dużą popularność. [Czytaj dalej]

Wywodzę się z branży budowlanej, gdzie króluje podejście tradycyjne w kwestii projektu. Nie wyobrażam sobie tworzenia budynku w sposób zwinny 🤔. Projektanci wraz z kierownictwem muszą go starannie zaplanować z wyprzedzeniem. Dokonać wielu sprawdzeń sensowności stworzenia danego przedsięwzięcia 🏢. W sytuacji, gdy budowa już ruszy to nie ma innego wyjścia jak... [Czytaj dalej]