Доста често среќавам програмери кои не слушнале за СОЛИД принципите (ние . — Превод.) или објектно-ориентирано програмирање (OOP), или сте слушнале за нив, но не ги користете во пракса. Оваа статија ги опишува придобивките од принципите на OOP кои му помагаат на развивачот во неговата секојдневна работа. Некои од нив се добро познати, други не толку многу, така што статијата ќе биде корисна и за почетници и за искусни програмери.
Потсетуваме: за сите читатели на Habr - попуст од 10 рубли кога се запишувате на кој било курс Skillbox користејќи го промотивниот код на Habr.
Skillbox препорачува: Едукативен онлајн курс .
СУВО (Не се повторувај)
Прилично едноставен принцип, чија суштина е јасна од името: „Не се повторувај“. За програмер, ова значи потреба да се избегне дупликат код, како и можност да се користи апстракција во нивната работа.
Ако има два повторливи делови во кодот, тие треба да се комбинираат во еден метод. Ако хардкодираната вредност се користи повеќе од еднаш, вреди да се претвори во јавна константа.
Ова е неопходно за да се поедностави кодот и полесно да се одржува, што е главната цел на OOP. Исто така, не треба прекумерно да ја користите унијата, бидејќи истиот код нема да помине верификација и со OrderId и со SSN.
Капсулирање на промени
Софтверските производи на повеќето компании постојано се развиваат. Ова значи дека треба да се направат промени во кодот, тој треба да биде поддржан. Можете да си го олесните животот со користење на инкапсулација. Ова ќе ви овозможи поефикасно да ја тестирате и одржувате вашата постоечка база на кодови. .
Ако пишувате во Јава, тогаш .
Принцип на отворено/затворено
Овој принцип може лесно да се запомни со читање на следнава изјава: „Софтверските ентитети (класи, модули, функции итн.) треба да бидат отворени за проширување, но затворени за модификација“. Во пракса, тоа значи дека тие можат да дозволат промена на нивното однесување без промена на изворниот код.
Принципот е важен кога промените во изворниот код бараат ревизија на кодот, тестирање на единицата и други процедури. Кодот што го следи принципот отворено/затворено не се менува кога се проширува, така што има многу помалку проблеми со него.
Еве пример на код што го нарушува овој принцип.
Ако треба да промените нешто во него, ќе биде потребно многу време, бидејќи сите делови од кодот што имаат врска со саканиот фрагмент ќе треба да се променат.
Патем, отвореноста-затвореноста е еден од принципите на SOLID.
Принцип на единствена одговорност (СРП)
Друг принцип од комплетот SOLID. Во него се наведува дека „постои само една причина што предизвикува промена во класата“. Часот решава само еден проблем. Може да има неколку методи, но секој од нив се користи само за решавање на заеднички проблем. Сите методи и својства треба да служат само за ова.
Вредноста на овој принцип е тоа што ја олабавува спојката помеѓу индивидуалната софтверска компонента и кодот. Ако додадете повеќе од една функционалност во класата, таа воведува врска помеѓу двете функции. Така, ако промените еден од нив, постои голема шанса да го уништите вториот, кој е поврзан со првиот. И ова значи зголемување на циклусите на тестирање со цел однапред да се идентификуваат сите проблеми.
Принцип на инверзија на зависност (DIP)
Погоре е пример за код каде што AppManager зависи од EventLogWriter, кој пак е тесно поврзан со AppManager. Ако ви треба поинаков начин за прикажување известување, било да е тоа push, SMS или е-пошта, треба да ја смените класата AppManager.
Проблемот може да се реши со помош на DIP. Значи, наместо AppManager, бараме EventLogWriter, кој ќе биде внесен со помош на рамката.
DIP овозможува лесно замена на поединечни модули со други со менување на модулот за зависност. Ова овозможува да се промени еден модул без да влијае на другите.
Состав наместо наследство
Постојат два главни начини за повторна употреба на кодот: наследување и состав, и двата имаат свои предности и недостатоци. Обично се претпочита вториот бидејќи е пофлексибилен.
Композицијата ви дава можност да го промените однесувањето на класата за време на извршувањето со поставување на нејзините својства. При имплементација на интерфејси, се користи полиморфизам, што дава пофлексибилна имплементација.
Дури и Effective Java од Џошуа Блох советува да изберете состав наместо наследство.
Принцип на замена на Барбара Лисков (ЛСП)
Друг принцип од комплетот алатки SOLID. Во него се наведува дека подтиповите мора да бидат заменливи за супертипот. Односно, методите и функциите што работат со суперкласа треба да можат да работат без проблеми со нејзините подкласи.
LSP е поврзан и со принципот на единствена одговорност и со принципот на заедничка одговорност. Ако класата обезбедува повеќе функционалност од подкласата, тогаш таа нема да поддржува дел од функционалноста, прекршувајќи го овој принцип.
Еве дел од кодот што е во спротивност со LSP.
Методот област (Правоаголник r) ја пресметува плоштината на правоаголникот. Програмата ќе падне по извршувањето на Square затоа што плоштадот не е правоаголник овде. Според принципот LSP, функциите кои користат референци за базни класи треба да можат да користат објекти од изведени класи без дополнителни инструкции.
Овој принцип, кој е специфична дефиниција за подтип, беше предложен од Барбара Лисков во главниот говор на конференцијата во 1987 година насловен „Апстракција на податоци и хиерархија“, оттука и неговото име.
Принцип за раздвојување на интерфејс (ISP)
Уште еден СОЛИД принцип. Според него, интерфејс што не се користи не треба да се имплементира. Следењето на овој принцип му помага на системот да остане флексибилен и погоден за рефакторирање кога се прават промени во оперативната логика.
Најчесто, оваа ситуација се јавува кога интерфејсот содржи неколку функции одеднаш, а на клиентот му треба само една од нив.
Бидејќи пишувањето интерфејс е тешка задача, ќе биде предизвик да го промените откако ќе заврши работата без да прекршите ништо.
Предноста на принципот на интернет провајдерот во Јава е што прво мора да се имплементираат сите методи, а дури потоа да можат да се користат од класите. Затоа, принципот овозможува да се намали бројот на методи.
Програмирање за интерфејсот, а не за имплементација
Сè овде е јасно од името. Примената на овој принцип води до создавање на флексибилен код кој може да работи со секоја нова имплементација на интерфејсот.
Треба да го користите типот на интерфејс за променливи, типови на враќање или тип на аргумент на методот. Пример е користењето на SuperClass наместо Подкласа.
Т.е.:
Листа на броеви= getNumbers();
Но не:
ArrayList броеви = getNumbers();
Еве практична имплементација на она што е дискутирано погоре.
Принцип на делегирање
Чест пример се методите equals() и hashCode() во Јава. Кога е потребно да се споредат два објекти, оваа акција се делегира на соодветната класа наместо на клиентската.
Предноста на принципот е што нема дуплирање на кодот и релативно е едноставно да се промени однесувањето. Тоа важи и за делегирање на настани.
Сите овие принципи ви дозволуваат да напишете пофлексибилен, убав и сигурен код со висока кохезија и ниска спојка. Се разбира, теоријата е добра, но за развивачот навистина да го искористи стекнатото знаење, потребна е пракса. Откако ќе ги совладате принципите на OOP, вашиот следен чекор може да биде да научите шеми за дизајн за да ги решите вообичаените проблеми за развој на софтвер.
Skillbox препорачува:
- Практичен курс .
- Применет онлајн курс .
- Двегодишен практичен курс .
Извор: www.habr.com