Monolity – wielkie projekty składające się z setek klas ściśle powiązanych ze sobą. Czasem to nawet nie muszą być przesadnie wielkie te projekty jednak wystarczy, że klasy są ściśle powiązane ze sobą.
Co to znaczy ściśle powiązane ze sobą? Jeśli w jednej klasie użyjemy słowa new, żeby stworzyć obiekt innej klasy to właśnie ściśle powiązaliśmy te dwie klasy. Jedna bez drugiej żyć nie może, nie da się jednej z nich przenieść do innej biblioteki bez odpowiednich referencji. Jeśli chcemy zlecić komuś napisanie jakiegoś modułu do nasze aplikacji, to musimy dostarczyć całą implementację wszystkich zależnych klas. Jeśli mamy ciąg 3 ściśle powiązanych klas taki, że A używa B a B używa C i mając każdą z tych klas w osobnym assembly, nie jesteśmy wstanie zmienić klasy B na inną (np B’) wykonania stosownych poprawek w klasie A. I o te poprawki się w głównej mierze rozchodzi. W obecnych czasach chyba nikt nie ma wątpliwości, że software się zmienia. Jeśli się zmienia to trzeba wprowadzać zmiany. Jeśli zaś wprowadzać zmiany to łatwo i szybko a nie tak, że zmiana w klasie B powoduje potrzebę wprowadzenia zmian w klasie A. Jak to zrobić? Ano całkiem prosto. Klasy powinny zależeć od abstrakcji – czyli Dependency Inversion Principle. Jeśli zależą od abstrakcji to możemy je podmieniać w miarę łatwo. Jeśli użyjemy jakiegoś kontenera DI – takiego co konfiguracje ma w XML-u to poszczególne kawałki systemu możemy podmieniać na inne bez rekompilacji kodu. Czyż nie jest to piękne?
Monolity mają jeszcze jedną wadę. Jeżeli wszystko jest zależne od wszystkiego, klasy ściśle powiązane a każda zmiana wymaga przeorania setek miejsc w kodzie, żeby to to ruszyć w ogóle, to metody postępowania są dwie. Pierwsza, wprowadzanie jak najmniejszych zmian czyli w praktyce powolne uśmiercanie projektu przez zaniechanie modyfikacji. Druga, dodawanie cudownych rozwiązań w stylu tutaj parametr do funkcji, tam jakiś if a tutaj case. Tym sposobem zachodzi zjawisko powolnego gnicia kodu. Z każdą iteracją takich fantastycznych hack-ów kod staje się coraz mniej czytelny i coraz ciężej rozwijalny. Koniec końców spotka go to samo co w pierwszym przypadku – śmierć.
Modne ostatnio programowanie agile czy też programowanie zwinne oznacza w dużym uproszczeniu ciągłą ewolucję i ciągłe wprowadzanie zmian, tak żeby być elastycznym na potrzeby biznesu. Nie da się być agile budując monolity, nie da się być agile zaciągając coraz to nowe długi technologiczne. W końcu, nie da się być agile jeśli po roku czy dwóch wprowadzanie zmian zaczyna trwać dłużej i dłużej. Jeśli chcemy być agile to musimy bardzo mocno trzymać się zasad dobrego programowania. Musimy tworzyć elastyczne i otwarte konstrukcje zamiast monolitów. SOLID w tym bardzo pomaga chociaż nie jest to jedyna “religia”. Aby to zrobić trzeba poświęcić odpowiednią ilość czasu i potu aby wyprodukować dobry kawałek kodu.
If you want to go fast, go well. — Robert C. Martin
Klepanie na hurrraaa… na wczoraj…. na jutro… zazwyczaj kończy się bardzo źle.