1. Фирмена история
Искам да ви разкажа една история, която демонстрира How ООП помага в борбата със сложността на големите системи. Това е необходимо, за да разберете целта на OOP .
Имало едно време малка компания, която предоставяла междугалактически транспортни услуги...
Нека го наречем Galaxy Rush. В него работеха 5 човека. Единият работеше във финансите, вторият работеше в склад, третият извършваше доставките, четвъртият се занимаваше с реклама, а петият управляваше цялото предприятие.
Те бяха много трудолюбиви и успяваха във всичко. Компанията имаше добра репутация и направи много пари. Но всяка година имаше все повече и повече поръчки, така че шефът трябваше да наеме допълнителни служители. Още няколко за склад, още няколко за доставки, още един за финанси и допълнителен рекламен експерт за разширяване на пазарния дял на компанията.
И тогава започнаха проблемите. Имаше още хора и те започнаха да си пречат.
Маркетологът харчи източва банковата сметка за нова рекламна кампания, така че няма пари за закупуване на продукти, които спешно трябва да бъдат изпратени.
Складът разполага с 10 чисто нови хипер диска, които се изпращат до клиент веднъж месечно. Един куриер долетя и взе хипер диск за друг клиент, което доведе до забавяне на редовната поръчка за 10 хипер диска с месец. Първият куриер просто не знаеше, че другата поръчка се изпълнява от втория куриер.
Новият помощник-мениджър изпраща куриер с космически кораб, за да закупи още стоки. Междувременно всички останали чакат да се появи свободен космически кораб. Има тонове спешни доставки, но този асистент наблюдава само доставките и се опитва да върши работата си добре. Колкото по-добре един служител изпълнява задълженията си, толкова повече се намесва в работата на другите.
Анализирайки ситуацията, шефът разбира, че важни ресурси като космически кораб, пари и продукти не се използват оптимално. Вместо това те са подчинени на правилото „отлагаш, губиш“. Всеки служител би могъл да вземе ресурс, от който всеки друг се нуждае за работата си, като по този начин застраши останалите служители и компанията като цяло.
Трябваше да се направи нещо, затова шефът реши да раздели монолитната компания на няколко отдела. Той създава отдел за доставка, отдел за маркетинг, отдел за доставки, отдел за финанси и отдел за инвентар. Вече никой не можеше просто да вземе космическия кораб. Ръководителят на отдела за доставка получи цялата информация за доставките и издаде кораба на куриера с най-изгодната поръчка. Освен това складът не позволяваше на куриерите просто да вземат стоките, които искат. Вместо това вземането на продукти от склада се превърна в контролиран процес. Финансовият отдел не би отпуснал средства за маркетингова кампания, ако знаеше, че скоро ще има покупка. Всеки отдел имаше едно публично лице - ръководителят на отдела.Вътрешната структура на всеки отдел беше свой собствен бизнес. Ако куриер искаше да получи продукти, тя отиваше при управителя на склада, а не в склада. Ако е постъпила нова поръчка, тя е получена от ръководителя на отдела за доставка ( public-facing representative), а не от куриер ( someone not authorized to interact with the other departments).
С други думи, шефът консолидира ресурсите и действията, включващи ресурси, в групи (отдели) и също така забрани на другите да се намесват във вътрешните структури на отделите. Междуведомствените взаимодействия трябваше да минават през конкретен човек.
От гледна точка на ООП , това не е нищо повече от разделяне на програмата на обекти. Една монолитна програма от методи и променливи се превръща в програма, съставена от обекти. И обектите имат променливи и методи.
Проблемът беше, че всеки служител можеше да работи с всеки ресурс и да дава команди на всеки друг служител, всичко това без надзор or контрол. Наложихме малко ограничение, но постигнахме повече ред. Освен това успяхме да контролираме по-добре всичко.
Това е разделяй и владей в най-чистата му форма.
2. Как се създават програмите
Искам да засегна още една важна точка, която разкрива друго предимство на ООП . Виждате ли, че програмите прorчат повече на животни, отколкото на сгради? Те не са построени. Те са пораснали. Развитието е постоянна промяна. В строителството можете да имате добър план и да го следвате с точност. Това не е така при разработката на софтуер.
Много често в програмирането не можете да направите нещо по начина, по който сте планирали първоначално и трябва да преработвате много. Изискванията на клиентите се променят още по-често.
Но Howво ще стане, ако клиентът предостави много точна спецификация? Това прави нещата още по-лоши. Вижте Howво се случва с продукта във времето.
Успехът на продукта ще накара клиента да поиска да пусне нова version, а след това още една и още една. И, разбира се, всичко, което трябва да направите, е да добавите "малки промени" към съществуващия продукт. Така че можете да видите, че разработването на продукта е последователност от постоянни промени. Само мащабът на времето е различен. Нова version може да бъде пусната веднъж седмично, веднъж месечно or веднъж на всеки шест месеца.
И Howъв извод можем да направим от всичко това? Вътрешната структура на продукта трябва да се поддържа по начин, който позволява извършването на значителни (и незначителни) промени с минимално преработване.
Кохезия на обекта
Но да направите това е по-трудно, отколкото да решите да го направите. Вече казахме, че програмата се състои от обекти, които взаимодействат помежду си. Нека начертаем всички обекти на нашата програма на дъската, представяйки ги с точки. И нека начертаем стрелки от всеки обект (точка) към всички други обекти (точки), с които той взаимодейства.
Сега ще комбинираме обектите (точките) в групи. Точките трябва да се групират, ако връзките между тях са много по-интензивни от тези с други точки. Ако повечето от стрелките от една точка отиват към други точки в собствената й група, тогава групите са формирани правилно. Казваме, че точките в една група имат висока кохезия , докато точките в различни групи имат по-ниска кохезия.
Принцип на хлабаво свързване
Има "принцип на хлабавото свързване". Програмата е разделена на няколко части, които често са слоеве. Логиката на тези слоеве/части е тясно свързана с тяхната вътрешна структура и много слабо свързана с други слоеве/части. Взаимодействията между слоевете обикновено са много регулирани. Един слой може да препраща към втория слой и да използва само малко подмножество от неговите класове. Това е принципът на "разделяне на компанията на отдели", който видяхме по-рано, но в по-голям мащаб.
Резултатът е, че можем да реорганизираме отдел, Howто е необходимо, за да увеличим ефективността му и можем да наемем още повече хора за отдела и докато не променим протокола на взаимодействие с другите ни отдели, тогава всички напequalsи промени ще остават местни. Никой не трябва да учи нищо отново. Не е нужно да преработвате цялата система. Всеки отдел може да направи такава вътрешна оптимизация, ако са добре подбрани механизмите за междуведомствено взаимодействие.
Подбрано добре. Но Howво ще стане, ако не са избрани добре? Тогава капацитетът за промяна бързо се изчерпва и ще трябва да преработите цялата система. Това трябва да се прави от време на време. Не можете да предвидите бъдещето, но можете да сведете броя на повторенията до минимум.
Принцип на абстракцията
Изборът How са структурирани отделите и How те си взаимодействат е „ принципът на абстракцията “. В програмирането се използва за определяне на най-добрия начин за разделяне на програма на съставни части и How тези части трябва да си взаимодействат. Можем да приложим отново принципа, разделяйки получените части на части, докато не разбием програмата на отделни класове.
Скриването на вътрешната структура на тези части и стриктното ограничаване на взаимодействията с други части е капсулиране . Капсулирането и абстракцията са крайъгълните камъни на ООП . Една добра програма трябва да следва тези два принципа. В бъдеще ще разгледаме останалите принципи и ще проучим Howви ползи предоставят.