Често срећем програмере који нису чули за СОЛИД принципе (ми . — Превод) или објектно оријентисано програмирање (ООП), или сте чули за њих, али их не користите у пракси. Овај чланак описује предности ООП принципа који помажу програмеру у његовом свакодневном раду. Неки од њих су добро познати, други не толико, тако да ће чланак бити користан и за почетнике и за искусне програмере.
Подсећамо: за све читаоце Хабра - попуст од 10 рубаља при упису на било који Скиллбок курс користећи Хабр промотивни код.
Скиллбок препоручује: Образовни онлајн курс .
СУВО (не понављај се)
Прилично једноставан принцип, чија је суштина јасна из имена: „Не понављај се“. За програмера то значи потребу да се избегне дуплирање кода, као и могућност да користе апстракцију у свом раду.
Ако постоје два одељка која се понављају у коду, треба их комбиновати у један метод. Ако се чврсто кодирана вредност користи више пута, вреди је претворити у јавну константу.
Ово је неопходно како би се код поједноставио и олакшао одржавање, што је и главни циљ ООП-а. Не бисте требали превише користити унију, јер исти код неће проћи верификацију ни са ОрдерИд-ом ни са ССН-ом.
Енцапсулатинг Цхангес
Софтверски производи већине компанија се стално развијају. То значи да је потребно извршити промене у коду, треба га подржати. Можете олакшати свој живот коришћењем енкапсулације. Ово ће вам омогућити да ефикасније тестирате и одржавате постојећу базу кода. .
Ако пишете на Јави, онда .
Отворено/затворено принцип
Овај принцип се може лако запамтити читањем следеће изјаве: „Софтверски ентитети (класе, модули, функције итд.) треба да буду отворени за проширење, али затворени за модификацију.“ У пракси, то значи да могу дозволити да се њихово понашање промени без промене изворног кода.
Принцип је важан када промене изворног кода захтевају ревизију кода, тестирање јединица и друге процедуре. Код који прати принцип отворено/затворено се не мења када се прошири, тако да има много мање проблема са њим.
Ево примера кода који крши овај принцип.
Ако требате нешто да промените у њему, то ће потрајати доста времена, јер ће сви делови кода који имају везу са жељеним фрагментом морати да се промене.
Иначе, отвореност-затвореност је један од принципа СОЛИД-а.
Принцип јединствене одговорности (СРП)
Још један принцип из СОЛИД сета. У њему се наводи да „постоји само један узрок који изазива промену у класи. Час решава само један задатак. Може имати неколико метода, али сваки од њих се користи само за решавање заједничког проблема. Све методе и својства треба да служе само овоме.
Вредност овог принципа је у томе што лабави везу између појединачне софтверске компоненте и кода. Ако додате више од једне функционалности у класу, она уводи однос између две функције. Дакле, ако промените једну од њих, постоји велика шанса да уништите другу, која је повезана са првом. А то значи повећање циклуса тестирања како би се унапред идентификовали сви проблеми.
Принцип инверзије зависности (ДИП)
Изнад је пример кода где АппМанагер зависи од ЕвентЛогВритер-а, који је заузврат уско повезан са АппМанагер-ом. Ако вам је потребан другачији начин да прикажете обавештење, било да је то пусх, СМС или имејл, морате да промените класу АппМанагер.
Проблем се може решити помоћу ДИП-а. Дакле, уместо АппМанагер-а, захтевамо ЕвентЛогВритер, који ће бити унет помоћу оквира.
ДИП омогућава лаку замену појединачних модула другим променом модула зависности. Ово омогућава промену једног модула без утицаја на друге.
Састав уместо наслеђа
Постоје два главна начина за поновно коришћење кода: наслеђивање и састав, од којих оба имају своје предности и мане. Обично се преферира други јер је флексибилнији.
Композиција вам даје могућност да промените понашање класе у току извршавања тако што ћете поставити њена својства. Приликом имплементације интерфејса користи се полиморфизам који даје флексибилнију имплементацију.
Чак и Ефективна Јава од Џошуе Блоха саветује да се изабере композиција уместо наслеђивања.
Барбара Лисков Принцип замене (ЛСП)
Још један принцип из СОЛИД комплета алата. Он каже да подтипови морају бити заменљиви за супертип. То јест, методе и функције које раде са суперкласом треба да буду у стању да раде без проблема са њеним подкласама.
ЛСП је повезан са принципом јединствене одговорности и принципом подељене одговорности. Ако класа пружа више функционалности од поткласе, онда ова друга неће подржавати неке од функционалности, кршећи овај принцип.
Ево дела кода који је у супротности са ЛСП-ом.
Метода ареа(правоугаоник р) израчунава површину правоугаоника. Програм ће се срушити након извршавања Скуаре јер Скуаре овде није правоугаоник. Према ЛСП принципу, функције које користе референце на основне класе треба да буду у стању да користе објекте изведених класа без додатних инструкција.
Овај принцип, који је специфична дефиниција подтипа, предложила је Барбара Лисков на конференцији 1987. године под насловом „Апстракција и хијерархија података“, отуда и његово име.
Принцип раздвајања интерфејса (ИСП)
Још један СОЛИД принцип. Према њему, интерфејс који се не користи не би требало да се имплементира. Праћење овог принципа помаже систему да остане флексибилан и погодан за рефакторисање када се изврше промене у оперативној логици.
Најчешће се ова ситуација дешава када интерфејс садржи неколико функција одједном, а клијенту је потребна само једна од њих.
Пошто је писање интерфејса тежак задатак, промена након што је посао завршен, а да се ништа не поквари, биће изазов.
Предност ИСП принципа у Јави је у томе што се прво морају имплементирати све методе, а тек онда их класе могу користити. Дакле, принцип омогућава смањење броја метода.
Програмирање за интерфејс, а не за имплементацију
Овде је све јасно из имена. Примена овог принципа доводи до стварања флексибилног кода који може да ради са било којом новом имплементацијом интерфејса.
Требало би да користите тип интерфејса за променљиве, типове враћања или тип аргумента методе. Пример је коришћење СуперЦласс уместо СубЦласс.
То је:
Листа бројева= гетНумберс();
Али не:
АрраиЛист нумберс = гетНумберс();
Ево практичне примене онога што је горе дискутовано.
Принцип делегирања
Уобичајени пример су методе екуалс() и хасхЦоде() у Јави. Када је потребно упоредити два објекта, ова акција се делегира одговарајућој класи уместо клијентској.
Предност принципа је у томе што нема дуплирања кода и релативно је једноставно променити понашање. То се такође односи на делегирање догађаја.
Сви ови принципи вам омогућавају да пишете флексибилнији, лепши и поузданији код са високом кохезијом и ниском спрегом. Наравно, теорија је добра, али да би програмер заиста користио стечено знање, потребна је пракса. Када савладате ООП принципе, ваш следећи корак може бити да научите обрасце дизајна за решавање уобичајених проблема у развоју софтвера.
Скиллбок препоручује:
- Практични курс .
- Примењени онлајн курс .
- Двогодишњи практични курс .
Извор: ввв.хабр.цом