Программалык камсыздоону тажрыйбасы бар адам, башкалар тарабынан жазылган программалык кодду, алардын мансаптык жолунун негизинде соттун параметрлерин колдонот.
Кесиптик карьерамдын жүрүшүндө мен көптөгөн иштеп чыгуучуларды билдим жана миңдеген коддорду көрдүм жана иштеп чыгуучунун чеберчилигин баалоо керек болгондо мен негизинен эки факторду карадым:
Бактыга жараша, кээ бир негиздери же принциптери бар, бул кодирование мыкты болууга жардам берет.
SOLID аббревиатурасы:
S: бирдиктүү жоопкерчилик принциби
O: ачык-жабык принцип
L: Лисковду алмаштыруу принциби
I: Интерфейсти бөлүү принциби
D: Көзкарандылыктарды инверсиялоо принциби
Биринчи SOLID принцибине, тактап айтканда
Класстын (же модулдун) өзгөрүшүнө, өнүгүшүнө бир гана себеби болушу керек.
Концепциянын өзү өтө жөнөкөй, бирок ушул жөнөкөйлүккө жетүү үчүн, ишке ашыруу жолу өтө татаал болушу мүмкүн. Классты өзгөртүү үчүн бир гана себеп болушу керек.
Бирок эмне үчүн?
Эмне үчүн өзгөрүүнүн бир гана себеби болушу керек?
Мисалы, өзгөрүүнүн эки башка себеби бар болсо, эки башка топтун эки башка себептен бир эле код менен иштеши мүмкүн деп божомолдоого болот. Ар бири өз чечимдерин ишке ашырууга аргасыз болот, алар компиляцияланган тилде (мисалы, C ++, C # же Java), башка командаларга же тиркеменин башка бөлүктөрүнө туура келбеген модулдарды алып келиши мүмкүн.
Дагы бир мисал, эгер сиз которулган тилди колдонуп жатсаңыз, анда ар кандай себептерден улам бир эле классты же модулду кайрадан тестирлөөгө туура келет. Бул сапатты көзөмөлдөө үчүн көбүрөөк эмгекти, убакытты жана күчтү талап кылат.
Класстын же модулдун бирден-бир өзгөчөлүгүн аныктоо, тест жүргүзүү үчүн текшерүү тизмесин карап отургандан кыйла татаал.
Бирок, азыраак техникалык көз караш менен ойлонууга аракет кылалы, башкача айтканда, биздин класстын же модулдун колдонуучусун анализдеп көрөлү, аны ким колдонот. Биз иштеп чыгуучу тиркеменин же тутумдун колдонуучулары белгилүү бир модул тарабынан тейленип, ага өзгөртүүлөрдү киргизүүнү суранган адамдар болушу керек экендигин биз дайыма эсибизден чыгарбашыбыз керек. Кызмат кылгандар классты же модулду өзгөртүүнү суранышат.
Модулдардын айрым мисалдары жана аларды колдонуу:
Демек, биринчи кезекте модул менен маектешкен ролду ойногон актерлорду же актёрлорду издөө керек болсо, анда бардык ролдор менен адамдарды бириктирүү кыйынга турушу мүмкүн. Чакан компанияда бир адам бир нече ролду ойной алат, ал эми ири компанияда бир ролду ойногон бир нече адам болушу мүмкүн.
Адамдарды же колдонуучуларды эмес, ролдорду аныктоо акылга сыярлык окшойт.
Ошондуктан:
Келгиле, кээ бир мисалдарды карап көрөлү
Бизде китеп түшүнүгү жана анын иштеши камтылган Book классы бар дейли.
класс китеби {
getTitle () функциясы {
return "A Great Book";
}
getAuthor () функциясы {
return "Alessandro Baricco";
}
function nextpage () {
// кийинки бет
}
printCurrent Page () функциясы {
echo “учурдагы барактын мазмуну”;
}
}
Бул абдан нормалдуу класс. Бизде китеп бар, класс бизге аталышты бере алат, алар бизге авторду бере алышат жана андан ары жылышат. Акыр-аягы, ал учурдагы баракты экранда басып чыгара алат.
Бирок, бир аз көйгөй бар.
Book объектисин башкарууга катышкан актерлор жөнүндө ойлонуп, алар кимдер болушу мүмкүн?
Бул жерде эки башка актёр жөнүндө оңой эле ойлонсок болот: Китепти башкаруу (катары китепканачы аял) жана Маалыматтарды берүү механизми (колдонуучуга кандайча мазмун жеткирүүнү каалайбыз: экранда, колдонуучунун графикалык интерфейсинде, колдонуучунун текстинде гана, балким басып чыгарууда).
Ошондуктан бизде класс менен өз ара аракеттешкен эки башка актер бар.
Кыскача айтканда, бул класс төмөнкүлөрдү камтыйт:
бул көйгөй болушу мүмкүн, анткени ал бирдиктүү жоопкерчилик принцибин (СРП) бузат.
Кантип өзгөртө алабыз, бирдиктүү жоопкерчилик принцибин сактоо үчүн ушул кодексти кантип өркүндөтө алабыз?
Төмөнкү кодду карап көрүңүз:
класс китеби {
getTitle () функциясы {
return "Oceano Mare";
}
getAuthor () функциясы {
return "Alessandro Baricco";
}
функцияны буруш () {
// кийинки бет
}
getCurrentPage () функциясы {
echo “учурдагы барактын мазмуну”;
}
}
интерфейс принтери {
printPage функциясы ($ page);
}
класс StampaLibro Принтерди ишке ашырат {
printPages функциясы ($ page) {
echo $ page;
}
}
HtmlPrinter классы Принтерди ишке ашырат {
printPages функциясы ($ page) {
жаңырык ' '. $ бет. ' ';
}
}
Бул өтө жөнөкөй мисал презентацияны бизнес логикасынан кантип бөлүп алууну көрсөтөт жана SRPге ылайык, биздин долбоордун ийкемдүүлүгүндө чоң артыкчылыктарды берет.
Эми дагы бир мисалды карап көрөлү:
Жогоруда келтирилген мисалга окшош нерсе, объект өзүн презентациядан сактап калса болот.
класс китеби {
getTitle () функциясы {
return "Oceano Mare";
}
getAuthor () функциясы {
return "Alessandro Baricco";
}
функцияны буруш () {
// кийинки бет
}
getCurrentPage () функциясы {
return "Учурдагы барактын мазмуну";
}
Функцияны сактоо () {
$ filename = '/ документтер /'. $ this-> getTitolo (). '-'. $ this-> getAuthor ();
file_put_contents ($ файл аты, serialize ($ this));
}
}
Мурдагыдай эле, бул жерде дагы ар кандай актерлорду аныктай алабыз Китепти башкаруу (катары китепканачы аял) жана Туруктуулук. Ар бир барактан экинчи бетке өтүү жолубузду өзгөрткүбүз келген сайын, ушул классты өзгөртүшүбүз керек. Бизде өзгөрүүлөрдүн бир нече себептери болушу мүмкүн.
класс китеби {
getTitle () функциясы {
return "Oceano Mare";
}
getAuthor () функциясы {
return "Alessandro Baricco";
}
функцияны буруш () {
// кийинки бет
}
getCurrentPage () функциясы {
return "Учурдагы барактын мазмуну";
}
}
класс SimpleFilePersistence {
функцияны сактоо (Book $ book) {
$ filename = '/ документтер /'. $ book-> getTitle (). '-'. $ book-> getAuthor ();
file_put_contents ($ файлдын аты, serialize ($ book));
}
}
Туруктуулук операциясын башка класска которуу милдеттерди так бөлүп берет жана биз Book классына таасир этпестен туруктуулук методдорун алмаштыра алабыз. Мисалы, DatabasePersistence классын ишке ашыруу маанисиз болуп калат жана биздин китеп ишинин тегерегинде курулган бизнес логикабыз өзгөрбөйт.
Ачык / Жабык -> экинчи принцибин окуп улантыңыз
Ercole Palmeri
Veeam тарабынан Coveware кибер опузалап инциденттерге жооп берүү кызматтарын көрсөтүүнү улантат. Coveware криминалистика жана ремедиация мүмкүнчүлүктөрүн сунуштайт ...
Болжолдуу тейлөө заводду башкарууга инновациялык жана жигердүү мамиле кылуу менен мунай жана газ секторун революция кылып жатат.…
Улуу Британиянын CMA жасалма интеллект рыногунда Big Tech жүрүм-туруму жөнүндө эскертүү берди. Ал жерде…
Имараттардын энергетикалык натыйжалуулугун жогорулатуу үчүн Европа Биримдиги тарабынан иштелип чыккан "Case Green" Декрети өзүнүн мыйзам чыгаруу процессин аяктады ...
