W dzisiejszym artykule chciałbym Wam nieco opowiedzieć o tym jak pisać „dobry kodzik”. Część z Was pewnie spodziewa się ciekawych wzorców, praktyk oraz zasad dobrego programowania. Otóż nic bardziej mylnego! Ugryzę temat nieco z innej strony i postaram się pokazać Wam, że znajomość technicznych zagadnień nie zawsze wystarcza.
Entity jest to klasa, która podobnie jak value object nie jest jedynie strukturą danych, ale zawiera w sobie zachowania oraz chroni reguły biznesowe. Udostępnia również odpowiednie metody, ktore zmieniają jej stan oraz enkapsulują logikę dbając przy tym o nasze niezmienniki.
W ostatnim artykule na temat value object opowiedziałem Wam czym są value object’y, jak je zaimplementować oraz dlaczego w większości przypadków są lepsze od bezpośredniego używania wartości prymitywnych. Jeśli go jeszcze nie widzieliście to przed dalszym czytaniem zachęcam Was do zapoznania się z nim. Ten artykuł jest tylko jego rozszerzeniem bazującym na Waszych sugestiach oraz pytaniach.
Kompatybilność wsteczna to temat, który jest bardzo często świadomie lub nieświadomie pomijany. Wiele osób myśli, że kompatybilność wsteczną musimy zapewnić tylko i wyłącznie w momencie kiedy udostępniamy nasze API na zewnątrz np. stosując architekturę mikroserwisową lub wystawiając publiczne API. Nic bardziej mylnego!
Stosowanie wartości prymitywnych nie zawsze jest dobrym rozwiązaniem. Nie rzadko powoduje to bardzo dużą ilość problemów. Na szczęście z pomocą przychodzi nam value object.
Często słyszymy, że duplikacja kodu jest czymś złym. Niektórzy wręcz posuwają się do stwierdzenia, że to antywzorzec. Ale czy na pewno tak jest?
Programowanie obiektowe jest próbą przedstawienia świata rzeczywistego oraz relacji w nim zachodzących za pomocą obiektów. Abstrakcja, hermetyzacja, polimorfizm oraz dziedziczenie to cztery główne cechy, które opisują ten rodzaj programowania.
SOLID to zbiór 5 zasad, które uczą nas jak powinniśmy tworzyć nasze funkcje i klasy, aby nasz kod był łatwy w zrozumieniu, utrzymaniu, testowaniu oraz rozwijaniu.