ЧВРСТО који су 5 принципи објектно оријентисаног програмирања

Чврсте чврсте геометријске фигуре
Обука
1

СОЛИД је скраћеница која се односи на пет принципа објектно оријентисаног дизајна (ООД или ООП). Ово су смернице које програмери могу користити за стварање софтвера којим се лако управља, одржава и проширује. Разумевање ових концепата учиниће вас бољим програмером и помоћи вам да избегнете проблеме са управљањем софтвером. Шта значи бити добар програмер?

Свако са неким искуством у софтверском програмирању суди софтверском коду који су написали други, користећи параметре просудбе на основу њихове каријере.

Током своје професионалне каријере познавао сам много програмера и видео сам хиљаде редова кода и када треба да проценим вештину програмера, углавном гледам на два фактора:

  • Једноставност читања кода;
  • Колика је вероватноћа да ће њихов код деловати и еволуирати током времена.

Срећом, постоје неки основи или принципи који олакшавају бољи кодирање.

акроним СОЛИД означава:
S: принцип јединствене одговорности
O: принцип отворено-затворено
L: Принцип замене Лисков
I: Принцип сегрегације интерфејса
D: Принцип инверзије зависности

Почнимо са удубљивањем у први ЧВРСТИ принцип, наиме

Начело појединачне одговорности

Класа (или модул) треба да има само један разлог за промену, за развој.

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

Али зашто? 

Зашто је толико важно имати само један разлог за промену?

На пример, ако постоје два различита разлога за промену, могуће је да два различита тима могу радити на истом коду из два различита разлога. Свака ће морати да примени своје решење, које би у случају компајлираног језика (као што је Ц ++, Ц # или Јава) могло довести до модула који су некомпатибилни са другим тимовима или другим деловима апликације.

Још један пример, ако користите језик који се тумачи, можда ћете морати поново тестирати исту класу или модул из различитих разлога. То значи више рада, времена и труда за контролу квалитета.

Идентификовање једине особине коју класа или модул треба да имају је много сложеније од пуког прегледа контролне листе за покретање тестова. 

Али покушајмо да размишљамо са мање техничке тачке гледишта, односно, покушајмо да анализирамо корисника наше класе или модула, односно ко ће га користити. Фундаментални аспект који увек морамо имати на уму је чињеница да ће корисници апликације или система који развијамо, а које опслужује одређени модул, бити они који ће захтевати њихове измене. Они који добију услугу затражиће промену класе или модула. 

Неки примери модула и њихова употреба:

  • Модул за одржавање: корисника чине администратори база података и софтверске архитекте.
  • Извештајни модул: корисника чине канцеларијски радници, рачуновође и производња.
  • Модул за обрачун плаћања за систем управљања платним списком: корисници могу да укључују адвокате, менаџере и рачуновође.
  • Модул за претрагу текста за систем управљања библиотеком: корисника може представљати библиотекар или посетиоци и купци саме библиотеке.

Дакле, ако је први корак потрага за глумцима или глумцем који има улогу саговорника са модулом, повезивање појединаца са свим улогама може бити тешко. У малој компанији једна особа може играти више улога, док у великој компанији може бити више људи који имају једну улогу. 

Чини се разумнијим идентификовати улоге, а не људе или кориснике.

Стога:

  • корисник софтверског система дефинише разлоге за промену;
  • одговорност је породица функција која задовољава потребе одређеног актера, односно корисника система;
  • актери, корисник постаје извор промена за породицу функционалности које морају задовољити потребе корисника;
  • еволуција корисничких потреба, води развој функционалности;

ЧВРСТИ принципи

Погледајмо неколико примера

Претпоставимо да имамо класу Књига која садржи концепт књиге и њену функционалност.

цласс Боок {

    функција гетТитле () {

        повратак „Велика књига“;

    }

    функција гетАутхор () {

        повратак „Алессандро Бариццо“;

    }

    функција нектпаге () {

        // Следећа страна

    }

    функција принтЦуррентПаге () {

        ехо „садржај тренутне странице“;

    }

}

Ово је сасвим нормална класа. Имамо књигу, а разред нам може дати наслов, могу нам дати аутора и могу ићи даље. Коначно, такође је у стању да штампа тренутну страницу на екрану. 

Међутим, постоји мали проблем. 

Размишљајући о актерима укљученим у управљање објектом Књиге, ко би они могли бити? 

Овде се лако можемо сјетити два различита глумца: Управљање књигама (као библиотекар) И Механизам подношења података (на пример како желимо да испоручимо садржај кориснику: на екрану, графички кориснички интерфејс, само текстуални кориснички интерфејс, можда штампање). 

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

Укратко, ова класа чини комбинацију између:

  • пословна логика са 
  • презентација 

ово може представљати проблем јер крши принцип јединствене одговорности (СРП). 

Како се можемо променити, како можемо побољшати овај кодекс тако да поштује принцип јединствене одговорности?

Погледајте следећи код:

цласс Боок {

    функција гетТитле () {

        повратак „Оцеано Маре“;

    }

    функција гетАутхор () {

        повратак „Алессандро Бариццо“;

    }

    функција окрени страницу () {

        // Следећа страна

    }

    функција гетЦуррентПаге () {

        ехо „садржај тренутне странице“;

    }

}

интерфејс Штампач {

    функција принтПаге ($ страница);

}

класа СтампаЛибро имплементира Штампач {

    функција принтПагес ($ страница) {

        ецхо $ паге;

    }

}

 

класа ХтмлПринтер имплементира Принтер {

    функција принтПагес ($ страница) {

        одјек ' '. $ паге. ' ';

    }

}

Овај врло једноставан пример показује како одвојити презентацију од пословне логике, а у складу са СРП нуди велике предности у флексибилности нашег пројекта.

Погледајмо још један пример:

Пример сличан горе наведеном је када објекат може да се сачува и преузме из презентације.

цласс Боок {

    функција гетТитле () {

        повратак „Оцеано Маре“;

    }

    функција гетАутхор () {

        повратак „Алессандро Бариццо“;

    }

    функција окрени страницу () {

        // Следећа страна

    }

    функција гетЦуррентПаге () {

        ретурн "садржај тренутне странице";

    }

    функција саве () {

        $ филенаме = '/ документи /'. $ ово-> гетТитоло (). '-'. $ ово-> гетАутхор ();

        филе_пут_цонтентс ($ филенаме, сериализе ($ тхис));

    }

}

Као и раније, и овде можемо идентификовати различите актере попут Управљање књигама (као библиотекар) И Упорност. Кад год желимо да променимо начин на који прелазимо са странице на страницу, морамо да променимо ову класу. Можемо имати неколико разлога за промену.

цласс Боок {

    функција гетТитле () {

        повратак „Оцеано Маре“;

    }

    функција гетАутхор () {

        повратак „Алессандро Бариццо“;

    }

    функција окрени страницу () {

        // Следећа страна

    }

    функција гетЦуррентПаге () {

        ретурн "садржај тренутне странице";

    }

}

цласс СимплеФилеПерсистенце {

    фунцтион саве (Боок $ боок) {

        $ филенаме = '/ документи /'. $ боок-> гетТитле (). '-'. $ боок-> гетАутхор ();

        филе_пут_цонтентс ($ име датотеке, сериализовати ($ књига));

    }

}

Премештање операције упорности у другу класу јасно ће раздвојити одговорности и моћи ћемо да размењујемо методе упорности без утицаја на нашу класу Књиге. На пример, примена класе ДатабасеПерсистенце била би тривијална и наша пословна логика изграђена око операција књига неће се променити.

Наставите читати други принцип Отворено / Затворено ->

КСНУМКС коментар

Оставите коментар

Ваша емаил адреса не сара Објављено. Ја Цампи Соно обблигатори цонтрассегнати *

лишков принцип
Обука
Принцип замене Лискова, трећи ЧВРСТИ принцип

Дечје класе никада не би требало да утичу или мењају дефиниције типова родитељске класе. Концепт овог принципа представила је Барбара Лисков у уводном делу конференције 1987. године, а потом објавила у чланку заједно са Јаннетте Винг 1994. године. Њихова првобитна дефиниција ...

гоогле маркетинг трендови
Обука
Како користити Гоогле трендове за маркетинг у реалном времену

Једна од главних потешкоћа са којом су се компаније сусреле у 2020. години било је разумевање у којим производним секторима да диверзификују своје пословање: заправо, већина индустријских сектора претрпела је велике последице што је готово онемогућило компанијама да продру у њих, посебно као нови играч. Веома мало производних сектора ...

стратегија пословне интелигенције
metode
Стратегије за успешну пословну интелигенцију

Изградња успешне стратегије за вашу пословну интелигенцију започиње са тачном визијом циљева. У наставку видимо неке темељне тачке. Процена тренутне ситуације Била би велика грешка подцењивати овај аспект. Процена тренутне ситуације значи анализу процеса, структура ...