Przyczyny powstania OOP

1. Historia o firmie

Chcę opowiedzieć jedną historię, która pokazuje, jak OOP pomaga radzić sobie ze złożonością dużych systemów. Jest to konieczne, aby zrozumieć cel OOP .

Dawno, dawno temu istniała mała firma zajmująca się dostarczaniem towarów w kosmos ...

Nazwijmy to Galaxy Rush. A pracowało tam 5 osób. Jeden odpowiadał za finanse, drugi w magazynie, trzeci za dostawy, czwarty za reklamę, a piąty za wszystko.

Byli bardzo pracowici i wszystko im się udało. Firma miała dobrą reputację i zarabiała dużo pieniędzy. Ale z roku na rok zleceń było coraz więcej, więc dyrektor musiał zatrudnić dodatkowych pracowników. Kilka na magazyn, kilka na dostawy, kolejny kasjer i reklamodawca do rozszerzenia rynku.

A potem zaczęły się problemy. Było więcej ludzi i zaczęli sobie przeszkadzać.

Marketer wydaje wszystkie pieniądze na nową kampanię reklamową, aw kasie nie ma pieniędzy na zakup produktu, który trzeba pilnie wysłać.

Mamy na stanie 10 pudełek fabrycznie nowych hipernapędów, dostarczanych raz w miesiącu. Przyleciał kurier z jednym hipernapędem, a zamówienie na 10 hipernapędów od innego klienta musi czekać kolejny miesiąc. Pierwszy kurier po prostu nie wiedział o drugim zamówieniu, które realizuje drugi kurier.

Nowy zastępca reżysera wysyła kuriera na statek w celu zakupu towarów, a wszyscy inni czekają na pojawienie się dostępnego statku. Jest dużo pilnych dostaw, ale ten pomocnik tylko zarządza zakupami i stara się dobrze wykonywać swoją pracę. Im lepiej ktoś wykonywał swoje obowiązki, tym bardziej wtrącał się w sprawy innych.

Próbując przeanalizować sytuację, reżyser zdał sobie sprawę, że tak ważne zasoby jak statek, gotówka i towary nie są wydawane optymalnie, ale zgodnie z zasadą „kto pierwszy wstanie – ten i kapcie”. Każdy mógł zabrać zasób potrzebny wszystkim do pracy, narażając jednocześnie resztę pracowników i całą firmę jako całość.

Coś trzeba było zrobić i dyrektor postanowił podzielić monolityczną firmę na kilka działów. Był dział dostaw, dział marketingu, dział zakupów, dział finansowy i dział zapasów. Teraz nikt nie mógł tak po prostu wziąć statku. Dyrektor działu dostaw otrzymywał wszystkie informacje o dostawach i przekazywał statek kurierowi, którego zamówienie było bardziej opłacalne dla firmy. Magazyn nie pozwalał też żadnemu kurierowi na zabranie towaru, ale kontrolował ten proces. Dział finansowy nie mógłby dać pieniędzy na marketing, gdyby wiedział, że wkrótce nastąpi zakup. Każdy wydział miał jedną twarz publiczną - swojego szefa. Wewnętrzna organizacja każdego działu była jego wewnętrzną działalnością.Jeśli kurier chciał odebrać towar, szedł do kierownika magazynu, a nie do magazynu. Jeśli pojawił się nowy wniosek, przyjmował go dyrektor działu doręczeń ( public person), a nie kurier ( private person).

Innymi słowy, dyrektor łączył zasoby i działania na nich w grupy (wydziały) , a także zabraniał innym ingerować w wewnętrzną strukturę wydziałów. Kontakt mógł być stricte z konkretną osobą.

Z punktu widzenia OOP jest to nic innego jak podzielenie programu na obiekty. Program monolityczny składający się z funkcji i zmiennych staje się programem składającym się z obiektów. Obiekty zawierają zmienne i funkcje.

Problem polegał na tym, że każdy pracownik mógł pracować w sposób niekontrolowany z dowolnym zasobem i wydawać polecenia dowolnej osobie. Wprowadziliśmy małe ograniczenie, ale zyskaliśmy większy porządek. Mieli też lepszą kontrolę nad tym wszystkim.

Dziel i rządź w najczystszej postaci.

2. Proces tworzenia programów

Chciałbym poruszyć jeszcze jedną ważną kwestię, która ujawnia kolejną zaletę OOP . Widzisz, programy bardziej przypominają zwierzęta niż budynki. Nie są zbudowane, są uprawiane. Rozwój to ciągła zmiana. W budownictwie możesz mieć dobry plan i trzymać się go. Nie dotyczy to tworzenia oprogramowania.

Bardzo często w programowaniu czegoś nie da się zrobić w sposób, który sobie nakreśliłeś na początku i trzeba dużo przerabiać. Jeszcze częściej zmieniają się wymagania klientów.

A gdyby zleceniodawca projektu podał bardzo precyzyjną specyfikację? Potem jest jeszcze gorzej. Przyjrzyj się sytuacji produktu w czasie.

Sukces produktu doprowadzi do tego, że klient będzie chciał wypuścić jego nową wersję, a potem kolejną i kolejną. I oczywiście konieczne będzie tylko dodanie „drobnych zmian” do już istniejącego produktu. Dlatego rozwój produktu to ciąg ciągłych zmian. Tylko skala czasu jest inna. Każda nowa wersja może być wydawana raz w tygodniu, raz w miesiącu lub raz na sześć miesięcy.

I jaki wniosek można wyciągnąć z tego wszystkiego? Wewnętrzna struktura produktu musi być utrzymywana w takim stanie, aby możliwe było dokonanie znaczących (i nie takich) zmian przy minimalnych przeróbkach.

Łączność obiektów

Ale zrobienie tego jest trudniejsze niż podjęcie decyzji. Powiedzieliśmy już, że program składa się z obiektów, które wchodzą ze sobą w interakcje. Umieśćmy wszystkie obiekty naszego programu na tablicy, zaznaczając je pogrubionymi kropkami. I narysujemy strzałki od każdego obiektu (punktu) do wszystkich obiektów (punktów), z którymi oddziałuje.

Teraz połączymy obiekty (punkty) w grupy. Punkty należy połączyć w grupę, jeśli powiązania między nimi są znacznie silniejsze niż z pozostałymi punktami. Jeśli większość strzałek z punktu trafia do punktów własnej grupy, to podział na grupy odbył się prawidłowo. Punkty należące do tej samej grupy będziemy nazywać silnie połączonymi , a punkty z różnych grup - słabo połączonymi.

Zasada słabego sprzężenia

Nazywa się to „zasadą słabego sprzężenia”. Program podzielony jest na kilka części, często warstw, których logika jest silnie powiązana z ich wewnętrzną strukturą, a bardzo słabo z innymi warstwami/częściami. Zwykle interakcja warstw jest bardzo uregulowana. Jedna warstwa może uzyskać dostęp do drugiej i korzystać tylko z niewielkiej części jej klas. Ta sama zasada "podziału na wydziały" tylko na większą skalę.

Prowadzi to do tego, że możemy zreorganizować dział, zwiększyć jego efektywność, zatrudnić jeszcze więcej osób, ale jeśli nie zmienimy protokołu interakcji innych działów z naszym, to wszystkie wprowadzone zmiany pozostaną lokalne. Nikt nie musi się przekwalifikować. Nie musisz przerabiać całego systemu. Każdy dział może zaangażować się w taką wewnętrzną optymalizację, jeśli ogólne mechanizmy interakcji zostaną dobrze dobrane.

Dobrze dobrane. A co się stanie, jeśli zostaną wybrani bezskutecznie? Wtedy „ rezerwa zmian ” szybko się wyczerpie i cały system trzeba będzie przerobić. Należy to robić od czasu do czasu. Nie da się przewidzieć, co stanie się w przyszłości, ale możliwe jest ograniczenie liczby zmian do minimum.

Zasada abstrakcji

Wybór struktury działów i sposobu ich interakcji to „ Zasada abstrakcji ”. W programowaniu służy do określenia, na które części należy podzielić program i jak te części powinny oddziaływać. Zasadę tę można również zastosować do podziału powstałych części, dopóki nie podzielimy programu na osobne klasy.

A ukrywanie wewnętrznej struktury tych części i surowe ograniczenia interakcji z innymi częściami to enkapsulacja . Enkapsulacja + abstrakcja to kamienie węgielne OOP . Dobry program musi przestrzegać tych dwóch zasad. W przyszłości przyjrzymy się pozostałym zasadom i zrozumiemy, jakie zapewniają one korzyści.