Sporo czasu poświęciłem na elektronikę i mimo tego, że nie byłem i nie jestem przesadnie pedantyczny to tranzystory i rezystory zawsze miałem uporządkowane w klasterach z posklejanych pudełek po zapałkach lub woreczkach strunowych. Takie postępowanie powodowało, że zawsze wiedziałem gdzie szukać tego jednego rezystora, który właśnie potrzebowałem. Takie segregowanie nie ma znaczenia przy 10-20-50 elementach, można to jeszcze ogarnąć jednak przy 100 i więcej zaczyna być problemem. Dokładnie to samo dzieje się z klasami. Wraz ze wzrostem ilości klas rośnie potrzeba segregowania ich i dlatego klasy segreguje się w namespaceach, katalogach, bibliotekach etc. Common Closure Principle mówi, że klasy w ramach jednego assembly (lub jednostki publikacji czyli dll) powinny posiadać wspólne zamknięcie (closure) – wspólny sensowny obszar. Rozumiem to tak, że wszystkie klasy dzielące wspólną dziedzinę powinny znaleźć się w tej same bibliotece. Zasada ta ma głęboki sens. Bo przecież nie jest zbyt wygodne, że aby użyć jakiegoś zewnętrznego elementu (np. kontrolki) należy dodać dziesiąt różnych referencji. Najwygodniej było by gdyby należało by dodać jedną referencję. Z drugiej strony wprowadzając zmiany w jakiejś części systemu nie jest dobre jeśli musimy przegrzebać 3/4 budowanej aplikacji i wprowadzić zmiany w każdej jednej bibliotece. W przeciwnym wypadku zmiana jakiegoś założenia biznesowego spowoduje zmiany w np. 20 bibliotekach, a projekty wykorzystujące takie cudo… no cóż, również wymagają zmiany wszystkich 20 referencji. Więc dla własnej wygody i komfortu konsumentów naszych bibliotek warto pomyśleć przy porządkowaniu klas a należy pamiętać, że SOLID a w szczególności S czyli Single Responsibility Principle generuje dużo więcej klas niż to zwykle bywa przy kodowaniu nie SOLIDnym.
