Три обектно-ориентирани принципа на проектиране, които определено трябва да използвате!

Keylearnings:

Какъв е холивудският принцип?
Какво означава инверсия на зависимостта?
Какво се разбира под принципа на най-малкото знание?
Какво е закон за деметрите?

Вече говорихме за това защо спазването на определени правила може да ни спаси от набор от сини очи.

От една страна, ние не работим сами, особено по-големи проекти и нашите колеги също трябва да могат да работят с нашия код без нервен срив и да могат да го използват повторно.

Но разбира се и ние самите печелим от това.

Бабиният ябълков пай е най-добрият!

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

Затова в тази статия искаме да се справим с още три обектно-ориентирани принципа на проектиране.

Холивудският принцип

Не се обаждайте на нас, ние ви се обаждаме!

Или на немски: Ще се свържем с вас!

Това е начинът, по който агентите в Холивуд отстраняват кандидатите.

Веднага щом кандидатът се окаже подходящ, той ще бъде информиран за това от агента. Обратно, обаче, кандидатът не може да достигне до агента.

Събитията са обектно-ориентирана концепция, която работи точно според този принцип.

Например как работят събитията в текстов процесор?

Текстовият процесор, като Word, се състои от две области.

От една страна областта, в която редактирате вашия текстов документ, а от друга страна меню, в което можете да посочите шрифта, размера на шрифта или цвета на текста, например.

Кой е агентът тук и кой е кандидатът?

Вместо кандидат и агент, ние говорим за абонат и наблюдател в програмирането.

Със сигурност не би било особено ефективно, ако областта на документа постоянно пита менюто за форматиране дали потребителят е коригирал форматирането на текста.

Следователно, веднага щом потребителят преформатира текста чрез менюто, се задейства събитие, за което областта на документа се информира и след това реагира съответно.

Следователно в този пример менюто за форматиране поема ролята на наблюдател (агент), а областта на документа е абонатът, който чака известия от менюто.

Холивудският принцип е от особено значение във връзка с така наречените рамки.

Рамките са програмни библиотеки, които освобождават разработчика от определени стандартни задачи.

Например има рамки като Java FX, която поема взаимодействието с потребителя в графичен потребителски интерфейс за нас.

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

Принципът на инверсия на зависимостта

Следващият принцип, който искаме да разгледаме, е принципът на инверсия на зависимостта.

Този принцип поставя абстракцията и независимото изпълнение на преден план.

Ние не се занимаваме с електричеството, а само с щепсела и контакта.

За да можем да приложим този принцип, ние използваме т. Нар. Прокси модел, който позволява да се използва метод, независимо от конкретното му изпълнение.

Инструментът, който използваме за това, са интерфейсите на Java.

CRUD операции с база данни

Известен пример за принципа на инверсия на зависимостта е връзката към база данни чрез JPA (Java Persistence Architecture).

JPA служи като интерфейс към използваната система от бази данни.

Във всяка база данни се нуждаем от така наречените CRUD операции Създаване, четене, актуализиране и изтриване, с които можем да създаваме, четем, променяме и изтриваме записи в базата данни.

Изпълнението на тези операции обаче се различава между различните системи от бази данни.

Например, изпълнението на тези операции в база данни на Oracle е различно от тази в база данни MySql.

Без JPA ще трябва да напишем отделно изпълнение на CRUD за всяка система от бази данни.

Например, тогава ще имаме отделен метод за запазване, като saveSQL, savePostgresSQL или saveOracle за всяка система от бази данни .

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

Ако някой трябва да има идеята да промени системата на базата данни, са необходими подходящи корекции на кода.

Благодарение на интерфейса JPA, ние сме пощадени от това. В зависимост от използваната система от бази данни, можем динамично да прикачим подходящата реализация към JPA прокси (дори докато програмата работи).

Разработчикът, който иска да използва операцията CRUD, може след това да извика методите CRUD на интерфейса, например save, независимо от основната реализация.

Самите различни реализации са независими един от друг.

Принципът на най-малкото знание!

Говорили сме за това много пъти. Програмистите са мързеливи и винаги търсят начини да си спестят работата.

Един добър начин да направите това е да използвате работата, извършена от други разработчици.

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

И тук се появява така нареченият принцип на най-малкото знание или на немски принципът на малко знание.

Този принцип е от особено значение във връзка с дизайна на API (Приложен програмен интерфейс).

Със сигурност знаете и това? Ако имате въпрос. Към кого се обръщаш Добър приятел или непознат от пешеходната зона?

Вероятно предпочитате да се свържете с вашия приятел. Или?

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

Законът на Деметра препоръчва първо да попитаме приятел и чак тогава да се свържем с непознат, ако нашият приятел не може да ни помогне.

Кой е приятел и кой е непознат?

Със сигурност никога не сте пили бира с метод, клас или атрибут. Или? И така, как да определим в нашите програми кой е приятел и кой е непознат?.

Тъй като законът на Demiter е обектно-ориентиран принцип на проектиране, трябва да определим кои методи и атрибути на обект принадлежат на нашите приятели.

Логично е, че всички методи в един и същи клас са приятели помежду си. Следователно взаимното извикване на методи в един и същи клас е позволено в закона на Демитър.

Кой друг е един от нашите приятели?

По същия начин ние се позоваваме на всички обекти, които предаваме като параметри, когато извикваме метод като наши приятели.

Освен това всички обекти (и техните атрибути), които създаваме в един и същи клас, също принадлежат към нашия приятелски кръг.

Индикатор, че нарушавате Закона на Demiter е, ако извикванията на метода ви имат повече от един (.) Оператор.

Добре, нека практикуваме наученото с пример.

Ние сме в библиотека.

Библиотеката се състои от рафтове с книги.

За да картографираме този обектно-ориентиран в Java, имаме нужда от два класа. Един клас за рафтовете и един клас за самата библиотека.

Рафтовете с книги очевидно принадлежат към библиотеката. Следователно рафтовете са приятели с библиотеката.

Всяка лавица съдържа броя книги, които съдържа като атрибут.

Така че атрибутът брой книги е приятел на класа „Рафтове“, но не и на класа „Библиотека“ .

Защото да кажем, че искаме да разберем броя на книгите на десетия рафт на библиотеката. Как може да изглежда съответното извикване на метод?

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

Как можем да направим повикването в съответствие със Закона за деметрите?

За да заобиколим този проблем, трябва да добавим метод към класа на библиотеката, който директно връща броя книги на рафт.

Такъв метод може да изглежда така например.

Тъй като рафтовете са в библиотеката, атрибутът ralf е приятел на класа на библиотеката. Следователно Законът за деметрите не се нарушава в рамките на метода getAnzahlRegal.

Сега получаваме броя на книгите на рафт 10 със следното извикване на метод.

Тъй като методът getAnzahlInRegal е приятел на класа на библиотеката, в случая не сме нарушили Закона за деметрите.

Заключение: В тази статия научихте за още три обектно-ориентирани принципа на проектиране. Холивудският принцип е основата на така наречените рамки, които ни освобождават от много повтарящи се и често скучни рутинни задачи на практика.

Инверсията на зависимостите ни позволява да работим с API (интерфейси за програмиране на приложения), в които тя разделя дефиницията и изпълнението на функция.

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

Хареса ли ви статията? След това веднага ни последвайте във Facebook!

Ким Питър

Здравейте, казвам се Ким и искам да стана страхотен програмист. Участвате ли?