Kiedy wprowadza się reguły? Zazwyczaj wówczas, kiedy zjawiska zachodzące w danym środowisku zaczynają wymykać się spod kontroli. Weźmy np. pojazd komunikacji miejskiej. Jeżeli jest on praktycznie pusty, to można z niego wysiadać w tym samym momencie, w którym ktoś chce wsiąść – ta garstka pasażerów wyminie się w drzwiach w sposób intuicyjny. Jeśli jednak liczba wysiadających jak i wsiadających zwiększy się, to konieczna będzie już jakaś regulacja – np. wchodzimy i wychodzimy zawsze prawą stroną wejścia. Ta reguła okaże się jednak nietrafiona, jeśli pojazd będzie praktycznie zapełniony. Wówczas lepszym (nomen omen) wyjściem będzie wyjście pasażerów chcącym opuścić pojazd, a następnie wejście pasażerów chcących skorzystać z pojazdu. Taka reguła sprawdzi się w każdej sytuacji – będzie uniwersalna. Naturalną jej konsekwencją będzie to, że chcący skorzystać z pojazdu będą musieli czekać, aż opuszczą go wszyscy niezainteresowani dalszą jazdą. Próby przeforsowania lub zastosowania innego postępowania będą nielogiczne i skończą się najpewniej wypchnięciem wchodzącego przez wychodzących. Nie da się tego zrealizować inaczej i nawet jeśli będzie to niepożądane dla pasażera oczekującego (bo upał, bo deszcz, bo mróz, bo …), to przecież nie zrezygnuje ze stosowania tej reguły chcąc bezkonfliktowo korzystać z komunikacji publicznej.

Mając na uwadze ten przykład można zadać sobie pytanie dlaczego w przypadku konsekwencji innych reguł, osoby je stosujące postanawiają jednak wybiórczo ich nie stosować? Weźmy chociażby omawianą przeze mnie ostatnio regułę nazywania warunków – prowadzi ona do powstania kolejnych metod. Albo regułę jedno działanie – jedna metoda, ona także powoduje wysyp metod. A metoda pojedynczej odpowiedzialność? Ta na dodatek powoduje eskalację klas. No i kto to wszystko ogarnie? Za dużo tego, może jednak lepiej czasami sobie te reguły darować i nie mnożyć bytów? Wrzucić wszystko do jednego worka – będzie mniej metod, mniej klas – da się nad tym zapanować. Po co tyle tego?!

W tym momencie właśnie potraktowaliśmy konsekwencję stosowania reguł jako coś niepożądanego – jak niepotrzebny efekt uboczny, anomalię. Nie, nie tędy droga! Reguły te wymyślono po to, aby sprawnie pisać oprogramowanie zorientowane obiektowo. Dzięki temu zyskuje ono możliwość automatycznego testowania, elastyczność komponowania (wystarczy w danej kompozycji obiektów wymienić jeden z nich i już jest inne działanie), czytelność. W żadnym wypadku nie należy przeciwdziałać tym konsekwencjom, próbować im zapobiegać poprzez naginanie reguł, z których wynikają. Potrzebne jest coś innego – możliwość zapanowania nad tymi konsekwencjami.

I takie możliwości istnieją. Nadmiarem metod można zarządzać wyodrębniając je do specjalistycznych klas. Ha! To rozmnożą się nam klasy! Owszem – naturalna konsekwencja – i ją zatem poddajmy zarządzaniu. Klasy można układać w gotowe kompozycje, a te – wszak i one będą de facto klasami – przenosić na kolejny poziom abstrakcji – w repozytoria kompozycji, w fabryki. Czyli – po prostu – zamykać w moduły, których poziom złożoności będzie akceptowalny. Iść w tę stronę, korzystając po drodze z istniejących wzorców projektowych, ale nigdy nie starać się przeciwdziałać konsekwencjom stosowanych reguł.

Obserwując rozwój oprogramowania wyraźnie widać, że jego złożoność funkcjonalna rośnie, więc naturalną konsekwencją jest też, że rośnie złożoność jego kodu. Nie ma sensu jej przeciwdziałać, należy zacząć nad nią panować.