Три објектно-ориентирани принципи на дизајн што дефинитивно треба да ги користите! научете да програмирате
Учење на клучни зборови:
- Кој е холивудскиот принцип?
- Што значи Инверзија на зависност?
- Што се подразбира под принципот на најмало знаење?
- Што е закон за Деметри?
Ние веќе разговаравме за тоа зошто почитувањето на одредени правила може да нè спаси од мноштво сини очи.
Од една страна, ние не работиме сами, особено на поголеми проекти, а нашите колеги исто така мора да можат да работат со нашиот код без нервен слом и да можат повторно да го користат.
Но, секако и ние самите имаме корист од тоа.
Најдобра е питата со јаболка на баба!
Па, зошто да го смениме рецептот кога можеме да решиме проблем на докажан и, пред сè, познат начин.
Затоа, во оваа статија сакаме да се справиме со уште три објектно-ориентирани принципи на дизајн.
Холивудскиот принцип
Не јавувај не, ние ти се јавуваме!
Или на германски: willе ве контактираме!
Тоа е начинот на кој агентите во Холивуд гледаат како ги отфрлаат кандидатите.
Штом кандидатот се покаже како соодветен, тој ќе биде информиран за ова од страна на агентот. Спротивно на тоа, кандидатот не може да дојде до агентот.
Настаните се објектно-ориентиран концепт кој работи точно според овој принцип.
Како функционираат настаните, на пример, во рамките на процесорот?
Обработувач на текст, како што е Word, се состои од две области.
Од една страна областа во која го уредувате вашиот текстуален документ и од друга страна мени во кое можете да ги наведете фонтот, големината на фонтот или бојата на текстот, на пример.
Кој е агентот тука и кој е кандидатот?
Наместо кандидат и агент, зборуваме за претплатник и набудувач во програмирањето.
Сигурно не би било особено ефикасно доколку областа на документот постојано го прашува менито за форматирање дали корисникот го прилагодил форматирањето на текстот.
Затоа, штом корисникот го преформатирал текстот преку менито, се активира настан, за кој е информирана областа на документот, а потоа соодветно реагира.
Затоа, во овој пример, менито за форматирање ја презема улогата на набудувач (агент), а областа на документот е претплатник кој чека известувања од менито.
Холивудскиот принцип е од особено значење во врска со таканаречените рамки.
Рамките се програмски библиотеки што го ослободуваат развивачот од одредени стандардни задачи.
На пример, постојат рамки како што е Java FX, кој ја презема интеракцијата со корисникот на графички кориснички интерфејс за нас.
На пример, ако корисникот кликне на копче, ние сме информирани за ова дејство преку рамката и можеме соодветно да реагираме.
Принципот на инверзија на зависност
Следниот принцип што сакаме да го разгледаме е принципот на инверзија на зависност.
Овој принцип ја става апстракцијата и независната имплементација во преден план.
Не сме загрижени за електричната енергија, туку само за приклучокот и штекерот.
За да можеме да го имплементираме овој принцип, ние ја користиме таканаречената шема на прокси, што овозможува употреба на метод без оглед на неговата специфична имплементација.
Алатката што ја користиме за ова се интерфејсите Java.
Бази на податоци CRUD операции
Познат пример за принципот на инверзија на зависност е поврзувањето со базата на податоци преку ЈПА (Java Persistence Architecture).
JPA служи како интерфејс на користениот систем на база на податоци.
Во секоја база на податоци ни требаат таканаречени CRUD операции Креирање, читање, ажурирање и бришење со кои можеме да креираме, читаме, модифицираме и бришеме записи во базата на податоци.
Сепак, спроведувањето на овие операции се разликува помеѓу различните системи на бази на податоци.
На пример, спроведувањето на овие операции на базата на податоци на Oracle е различно отколку во базата на податоци MySql.
Без JPA ќе мора да напишеме посебна CRUD имплементација за секој систем на бази на податоци.
На пример, тогаш би имале посебен метод за зачувување како што се saveSQL, savePostgresSQL или saveOracle за секој систем на база на податоци .
И, развивачот што сака да ја користи операцијата за зачувување, ќе мора да проверува секој пат кога се користи системот за бази на податоци и, во зависност од ова, повикајте го правилниот метод CRUD.
Ако некој тогаш треба да има идеја да го смени системот на базата на податоци, неопходни се соодветни прилагодувања на кодот.
Благодарение на JPA интерфејсот, поштедени сме од тоа. Во зависност од користениот систем на база на податоци, можеме динамично да ја прицврстиме соодветната имплементација на прокси-JPA (дури и додека програмата работи).
Инвеститорот што сака да ја користи операцијата CRUD, тогаш може да го нарече интерфејсот CRUD методи, како што е зачувување, без оглед на основната имплементација.
Самите различни имплементации се независни едни од други.
Принципот на најмалку знаење!
Разговаравме за тоа многу пати. Програмерите се мрзливи и секогаш бараат начини да си заштедат работа.
Добар начин да го направите ова е да ја користите работата направена од други програмери.
Сепак, ова е корисно само ако времето за запознавање со кодот на странската програма е што е можно пократко.
И тука влегува во игра таканаречениот принцип на најмалку знаење или на германски принцип на малку познавање.
Овој принцип е од особено значење во врска со дизајнот на API (Application Programming Interface).
Вие сигурно го знаете и тоа? Ако имате прашање. Кому му се обраќаш Добар пријател или странец од зоната за пешаци?
Веројатно претпочитате да контактирате со вашиот познаник. Или?
И тоа е токму основата врз која се темели принципот на најмало знаење, кој е познат и под името Деметров закон.
Деметровиот закон препорачува прво да побараме пријател и само тогаш да контактираме странец ако нашиот другар не може да ни помогне.
Кој е пријател, а кој странец?
Сигурно никогаш не сте пиеле пиво со метод, час или атрибут. Или? Па, како да дефинираме во нашите програми кој е пријател и кој е странец?.
Бидејќи Демитеровиот закон е објектно-ориентиран принцип на дизајнирање, ние треба да утврдиме кои методи и атрибути на објектот им припаѓаат на нашите пријатели.
Логично е дека сите методи во иста класа се пријатели едни со други. Меѓусебното повикување на методите во иста класа е дозволено во Демитеровиот закон.
Кој друг е еден од нашите пријатели?
Исто така, ние се однесуваме на сите објекти што ги поминуваме како параметри кога повикуваме метод како наши пријатели.
Понатаму, сите предмети (и нивните атрибути) што ги создаваме во иста класа, исто така, припаѓаат на нашиот круг на пријатели.
Индикатор дека го кршите законот на Демитер е ако повиците на вашиот метод имаат повеќе од еден (.) Оператор.
Добро, да го вежбаме она што го научивме користејќи пример.
Ние сме во библиотека.
Библиотека е составена од полици за книги.
За да го мапираме овој објектно-ориентиран во Јава, потребни ни се две класи. Еден час за полиците и еден час за самата библиотека.
Полиците за книги очигледно припаѓаат на библиотеката. Затоа, полиците се пријатели со библиотеката.
Секоја полица за книги содржи број на книги што ги содржи како атрибут.
Значи, атрибутот за бројот на книги е пријател на часот на полица за книги, но не и на часот на Библиотека .
Затоа што да речеме дека сакаме да го откриеме бројот на книги на десеттата полица во библиотеката. Како може да изгледа соодветниот повик за метод?
Постојат две точки во нашата жалба. Очигледно тука го кршиме законот за Деметра. Навистина, атрибутот „број на книги“ не е пријател на часот по библиотека.
Како можеме да го направиме повикот усогласен со законот за Деметри?
За да го надминеме овој проблем, треба да додадеме метод на часот по библиотека што директно го враќа бројот на книги на полица.
Таков метод може да изгледа вака, на пример.
Бидејќи полиците се наоѓаат во библиотеката, атрибутот на полицата е пријател на часот по библиотека. Законот за Деметри не е прекршен во рамките на методот getAnzahlRegal.
Сега го добиваме бројот на книги на полицата 10 со следниот повик за метод.
Бидејќи методот getAnzahlInRegal е пријател на часот по библиотека, ние не го прекршивме законот за Деметра во овој случај.
Заклучок: Во оваа статија научивте за уште три објектно-ориентирани принципи на дизајн. Холивудскиот принцип е основа за таканаречените рамки што нè ослободуваат од многу повторувачки и често досадни рутински задачи во пракса.
Инверзијата на зависност ни овозможува да работиме со API’s (Application Programming Interfaces) со одвојување на дефиницијата и имплементација на функција.
Основната грижа на сите принципи на дизајнирање, но особено со принципот на најмалку знаење, полесно е да го направите вашиот код повеќекратно, полесен за разбирање и попријателски за одржување.
Дали ви се допадна статијата? Потоа следете не на Фејсбук веднаш!
Ким Питер
Здраво, јас се викам Ким и сакам да станам одличен програмер. Дали учествувате?