Często spotykam się z kodem źródłowym, w którym klasy służą tylko do opakowania wielu zmiennych w celu zwrócenia wyniku funkcji. Typy nie powinny być kubełkami wartości tylko odzwierciedleniem idei i zamysłów programisty.
Jakiś czas temu nie łatwo było mi przekonać znajomego dlaczego stworzyłem osobny typ reprezentujący język aplikacji zamiast wykorzystania zmiennej typu znakowego.
Ostatnio jednak wpadłem na jeszcze lepszy przykład wprost z aplikacji, nad którą aktualnie pracujemy. Główna ideą aplikacji CMS jest zarządzanie stronami i sekcjami, w których strony są umieszczane. Każda strona posiada swój unikalny adres.
Powiedzmy, że nie jest to takie tragiczne rozwiązanie ale tylko do momentu kiedy zechcemy dodawać i usuwać wersję językową do adresu. W takim wypadku musielibyśmy dodać dodatkowe metody do klasy strony.
Co jednak jeżeli chcielibyśmy wykonać jaką operację na samym tylko adresie np. pobranie nazwy strony albo wersji językowej? Zawsze możemy zastosować klasy pomocnicze.
O ile taka implementacja pozwoli nam osiągnąć zamierzony cel, o tyle nie ma ona prawie nic wspólnego z programowaniem zorientowanym obiektowo. Dobry rozwiązaniem byłoby stworzenie osobnego typu reprezentującego adres strony. Przeniesienie logiki operacji na adresie do osobnej klasy pozwala nam używać tego typu w klasie strony ale także niezależnie jeżeli potrzebujemy operować na samym tylko adresie.
Co z tych rozważań wynika? Oczywiście nic nie stoi na przeszkodzie aby stosować styl proceduralny w języku zorientowanym obiektowo. Jednak tracimy wtedy wszystkie zalety naszego narzędzia, płynąć pod prąd wyrządzamy sobie sami szkodę. Problemy nie pojawią się na początku projektu kiedy złożoność jest niska. Dadzą się we znaki kiedy entropia odpowiednio wzrośnie. Dlatego trzeba złożoność systemu rozbijać na małe moduły, które wstydliwie ukrywają przed światem szczegóły ze swojej prywatności.
lecę gdzieś w przepaść, widzę czane dno
1 tydzień temu
