Свако са неким искуством у софтверском програмирању суди софтверском коду који су написали други, користећи параметре просудбе на основу њихове каријере.
Током своје професионалне каријере познавао сам много програмера и видео сам хиљаде редова кода и када треба да проценим вештину програмера, углавном гледам на два фактора:
Срећом, постоје неки основи или принципи који олакшавају бољи кодирање.
акроним СОЛИД означава:
S: принцип јединствене одговорности
O: принцип отворено-затворено
L: Принцип замене Лисков
I: Принцип сегрегације интерфејса
D: Принцип инверзије зависности
Почнимо са удубљивањем у први ЧВРСТИ принцип, наиме
Класа (или модул) треба да има само један разлог за промену, за развој.
Сам концепт је врло једноставан, али да би се постигла ова једноставност, пут примене може бити веома сложен. Разред треба да има само један разлог за промену.
Али зашто?
Зашто је толико важно имати само један разлог за промену?
На пример, ако постоје два различита разлога за промену, могуће је да два различита тима могу радити на истом коду из два различита разлога. Свака ће морати да примени своје решење, које би у случају компајлираног језика (као што је Ц ++, Ц # или Јава) могло довести до модула који су некомпатибилни са другим тимовима или другим деловима апликације.
Још један пример, ако користите језик који се тумачи, можда ћете морати поново тестирати исту класу или модул из различитих разлога. То значи више рада, времена и труда за контролу квалитета.
Идентификовање једине особине коју класа или модул треба да имају је много сложеније од пуког прегледа контролне листе за покретање тестова.
Али покушајмо да размишљамо са мање техничке тачке гледишта, односно, покушајмо да анализирамо корисника наше класе или модула, односно ко ће га користити. Фундаментални аспект који увек морамо имати на уму је чињеница да ће корисници апликације или система који развијамо, а које опслужује одређени модул, бити они који ће захтевати њихове измене. Они који добију услугу затражиће промену класе или модула.
Неки примери модула и њихова употреба:
Дакле, ако је први корак потрага за глумцима или глумцем који има улогу саговорника са модулом, повезивање појединаца са свим улогама може бити тешко. У малој компанији једна особа може играти више улога, док у великој компанији може бити више људи који имају једну улогу.
Чини се разумнијим идентификовати улоге, а не људе или кориснике.
Стога:
Погледајмо неколико примера
Претпоставимо да имамо класу Књига која садржи концепт књиге и њену функционалност.
цласс Боок {
функција гетТитле () {
повратак „Велика књига“;
}
функција гетАутхор () {
повратак „Алессандро Бариццо“;
}
функција нектпаге () {
// Следећа страна
}
функција принтЦуррентПаге () {
ехо „садржај тренутне странице“;
}
}
Ово је сасвим нормална класа. Имамо књигу, а разред нам може дати наслов, могу нам дати аутора и могу ићи даље. Коначно, такође је у стању да штампа тренутну страницу на екрану.
Међутим, постоји мали проблем.
Размишљајући о актерима укљученим у управљање објектом Књиге, ко би они могли бити?
Овде се лако можемо сјетити два различита глумца: Управљање књигама (као библиотекар) И Механизам подношења података (на пример како желимо да испоручимо садржај кориснику: на екрану, графички кориснички интерфејс, само текстуални кориснички интерфејс, можда штампање).
Стога имамо два врло различита глумца који комуницирају са разредом.
Укратко, ова класа чини комбинацију између:
ово може представљати проблем јер крши принцип јединствене одговорности (СРП).
Како се можемо променити, како можемо побољшати овај кодекс тако да поштује принцип јединствене одговорности?
Погледајте следећи код:
цласс Боок {
функција гетТитле () {
повратак „Оцеано Маре“;
}
функција гетАутхор () {
повратак „Алессандро Бариццо“;
}
функција окрени страницу () {
// Следећа страна
}
функција гетЦуррентПаге () {
ехо „садржај тренутне странице“;
}
}
интерфејс Штампач {
функција принтПаге ($ страница);
}
класа СтампаЛибро имплементира Штампач {
функција принтПагес ($ страница) {
ецхо $ паге;
}
}
класа ХтмлПринтер имплементира Принтер {
функција принтПагес ($ страница) {
одјек ' '. $ паге. ' ';
}
}
Овај врло једноставан пример показује како одвојити презентацију од пословне логике, а у складу са СРП нуди велике предности у флексибилности нашег пројекта.
Погледајмо још један пример:
Пример сличан горе наведеном је када објекат може да се сачува и преузме из презентације.
цласс Боок {
функција гетТитле () {
повратак „Оцеано Маре“;
}
функција гетАутхор () {
повратак „Алессандро Бариццо“;
}
функција окрени страницу () {
// Следећа страна
}
функција гетЦуррентПаге () {
ретурн "садржај тренутне странице";
}
функција саве () {
$ филенаме = '/ документи /'. $ ово-> гетТитоло (). '-'. $ ово-> гетАутхор ();
филе_пут_цонтентс ($ филенаме, сериализе ($ тхис));
}
}
Као и раније, и овде можемо идентификовати различите актере попут Управљање књигама (као библиотекар) И Упорност. Кад год желимо да променимо начин на који прелазимо са странице на страницу, морамо да променимо ову класу. Можемо имати неколико разлога за промену.
цласс Боок {
функција гетТитле () {
повратак „Оцеано Маре“;
}
функција гетАутхор () {
повратак „Алессандро Бариццо“;
}
функција окрени страницу () {
// Следећа страна
}
функција гетЦуррентПаге () {
ретурн "садржај тренутне странице";
}
}
цласс СимплеФилеПерсистенце {
фунцтион саве (Боок $ боок) {
$ филенаме = '/ документи /'. $ боок-> гетТитле (). '-'. $ боок-> гетАутхор ();
филе_пут_цонтентс ($ име датотеке, сериализовати ($ књига));
}
}
Премештање операције упорности у другу класу јасно ће раздвојити одговорности и моћи ћемо да размењујемо методе упорности без утицаја на нашу класу Књиге. На пример, примена класе ДатабасеПерсистенце била би тривијална и наша пословна логика изграђена око операција књига неће се променити.
Наставите читати други принцип Отворено / Затворено ->
Ercole Palmeri
УК ЦМА је издао упозорење о понашању Биг Тецх-а на тржишту вештачке интелигенције. Тамо…
Уредба „Цасе Греен“, коју је формулисала Европска унија за побољшање енергетске ефикасности зграда, завршила је свој законодавни процес са…
Представљен годишњи извештај Цасалеггио Ассоциати-а о е-трговини у Италији. Извештај под насловом „АИ-Цоммерце: границе е-трговине са вештачком интелигенцијом“.…
Резултат сталних технолошких иновација и посвећености животној средини и добробити људи. Бандалук представља Аирпуре®, шатор…
