Sugerowałbym, że najważniejszą cechą programowania obiektowego jest zarządzanie złożonością .
Ludzki mózg może jednocześnie przechowywać tak wiele pojęć - często pojawia się często cytowany limit zapamiętywania 7 +/- 2 niezależnych elementów.
Kiedy pracuję nad systemem 600kloc w pracy, nie mogę od razu trzymać tego wszystkiego w głowie. Gdybym musiał to zrobić, ograniczałbym się do pracy na znacznie mniejszych systemach.
Na szczęście nie muszę. Różne wzorce projektowe i inne struktury, które zastosowaliśmy w tym projekcie, oznaczają, że nie muszę zajmować się całym systemem na raz - mogę zbierać pojedyncze elementy i pracować nad nimi, wiedząc, że pasują one do szerszej aplikacji na dobrze określone sposoby.
Wszystkie ważne koncepcje OO zapewniają sposoby zarządzania złożonością.
Hermetyzacja - pozwól mi poradzić sobie z zewnętrznym interfejsem API, który zapewnia mi różne usługi, bez obawy, jak te usługi są wdrażane.
Abstrakcja - pozwolę sobie skoncentrować się na podstawowych cechach i zignorować to, co nieistotne.
Kompozycja - pozwól mi ponownie użyć komponentów, które zostały już zbudowane w nowych kombinacjach
Polimorfizm - pozwól mi poprosić o usługę, nie martwiąc się o to, w jaki sposób różne obiekty mogą to zapewniać na różne sposoby.
Dziedziczenie - pozwól mi ponownie użyć interfejsu lub implementacji, podając tylko te elementy, które różnią się od poprzednich.
Zasada pojedynczej odpowiedzialności - pozwala zachować cel dla każdego obiektu jasny i zwięzły, dzięki czemu łatwo jest go zrozumieć
Zasada substytucji Liskowa - nie zastawiajmy sobie pułapek, wprowadzając dziwne zależności
Zasada Otwarta / Zamknięta - zezwólmy na rozszerzenie i modyfikację w sposób, który nie wymaga od nas ryzyka zepsucia istniejącego kodu
Dependency Injection - przenieśmy kompozycję na wyższy poziom i zmontuj elementy razem znacznie później.
Rozwój zorientowany na interfejs - przenieś abstrakcję na wyższy poziom i polegaj tylko na abstrakcji, nigdy na konkretnej implementacji.