„Здравей, Амиго! Бих искал да ти разкажа за още едно предимство на ООП. Виждаш ли, програмите прorчат повече на животни, отколкото на сгради. Те не се изграждат, те се отглеждат. Развитието означава постоянни промени. В строителството можете имайте добър план и го следвайте до T. Но при разработването на софтуер това не е така."

Доста често не можете да направите нещо по начина, по който сте възнамерявали, и трябва да преработвате програмата си много. И още по-често изискванията на клиента се променят.

„Но Howво ще стане, ако клиентът предостави наистина подробна спецификация?“

„Погледнете Howво се случва с времето. Ако даден продукт успее, клиентът ще иска да пусне нова version, а след това още една, и още една. И, разбира се, ще трябва да направите няколко „ малки промени “ в съществуващия продукт. Така че разработката на софтуер е дълга поредица от промени. Различава се само ритъмът. Нова version може да се пуска всяка седмица, веднъж месечно or на всеки шест месеца."

Java webinar

— И така, Howво заключение правим от всичко това?

„Вътрешната структура на продукта трябва да се поддържа по начин, който позволява извършването на големи (и незначителни) промени с минимална преработка.“

"Как правиш това?"

„Вече говорихме How една програма се състои от обекти, които взаимодействат един с друг. Нека използваме дебели точки, за да представим всички обекти на нашата програма на дъската. Ще начертаем стрелки от всеки обект (точка) към всички обекти (точки), с които взаимодейства."

Сега нека комбинираме обектите (точките) в групи. Точките принадлежат към една и съща група, ако са много по-свързани една с друга от другите точки. Ако по-голямата част от стрелките на точката сочат към точките в нейната група, значи сме групирали правилно обектите. Точките в една и съща група се наричат ​​тясно свързани, докато точките в различни групи са слабо свързани.

Това се нарича « принцип на слабо свързване ». Програмата е разделена на няколко части, често слоеве, чиято логика е тясно свързана с тяхната вътрешна структура и слабо свързана с други слоеве/части. Взаимодействието между слоевете обикновено е силно разделено. Един слой може да извика друг слой, използвайки само малко подмножество от своите класове.

— Същият принцип на „разделение на труда“, но в по-голям мащаб?

„Точно. Това ни позволява да реорганизираме отдел, да го направим по-ефективен и да наемем още повече хора и ако не променим междуведомствените протоколи, тогава всички наши промени ще бъдат локални. Никой не трябва да бъде преквалифициран. Ние не Трябва да преработим цялата система. Всеки отдел може да оптимизира вътрешните си работи по този начин, ако механизмите за взаимодействие между отделите са добре подбрани."

"Ако са избрани добре. И Howво, ако не са избрани добре?"

„Тогава бързо ще ви свърши „ пространството за въртене “ за извършване на промени и ще трябва да преработите цялата система. Това се случва от време на време. Не можем да предвидим бъдещето, но можем да минимизираме броя пъти, които трябва да пренапишем програмата."

„Добре. Виждам ползата от разделянето на програмата по този начин, но How ООП влиза в картината?“

„Когато избираме How да структурираме отделите и How те ще си взаимодействат, ние прилагаме „ принципа на абстракцията “. В програмирането абстракцията се използва, за да се определи най-добрият начин за разделяне на програмата и How трябва да си взаимодействат частите. Този принцип може също да се прилага многократно към съставните части, докато не разделим програмата на отделни класове."

„И скриването на вътрешната структура на тези части и стриктното ограничаване на начина, по който взаимодействат с други части – това е капсулиране , нали?“

"Точно така. Капсулирането и абстракцията са крайъгълните камъни на ООП. Добрата програма трябва да се придържа към тези два принципа. По-късно ще разгледаме други принципи и ще разберем техните предимства."

„Хубави неща. Нямам търпение!“