Секој со одредено искуство во софтверско програмирање суди за софтверски код напишан од други, користејќи параметри за проценка засновани врз нивниот пат во кариерата.
Во текот на мојата професионална кариера, познавав многу развивачи и видов илјадници редови на кодови и кога треба да ја проценам вештината на инвеститорот, главно разгледувам два фактори:
За среќа, постојат некои основи или принципи што го олеснуваат подобриот кодирање.
кратенката SOLID се залага за:
S: принцип на единствена одговорност
O: принцип отворено затворено
L: Принцип на замена на Лисков
I: Принцип на поделба на интерфејсот
D: Принцип на превртување на зависностите
Да започнеме со навлегување во првиот принцип на СОЛИД, имено
Класа (или модул) треба да има само една причина да се менува, да се развива.
Самиот концепт е многу едноставен, но за да се постигне оваа едноставност, патот за спроведување може да биде многу комплициран. Часот треба да има само една причина да се промени.
Но зошто?
Зошто е толку важно да се има само една причина да се промени?
На пример, ако има две различни причини за промена, може да се замисли дека два различни тима би можеле да работат на ист код од две различни причини. Секој ќе мора да имплементира свое решение, што во случај на компилиран јазик (како C ++, C # или Java), може да доведе до модули што не се компатибилни со други тимови или други делови од апликацијата.
Друг пример, ако користите толкуван јазик, можеби ќе треба повторно да ја тестирате истата класа или модул од различни причини. Ова значи повеќе работа, време и напор за контрола на квалитетот.
Идентификувањето на единствената карактеристика што треба да ја има класа или модул е многу покомплексно отколку едноставно гледање во список за проверка за извршување тестови.
Но, ајде да се обидеме да размислиме од помалку техничка гледна точка, односно, да се обидеме да го анализираме корисникот на нашата класа или модул, односно кој ќе го користи. Основен аспект што секогаш мора да го имаме во предвид, е фактот дека корисниците на апликацијата или системот што ги развиваме, а на кои им служи одреден модул, ќе бидат оние што бараат измени во истиот. Оние што се опслужуваат ќе побараат промена на класата или модулот.
Неколку примери на модули и нивна употреба:
Значи, ако првиот чекор е да се бараат актерите или актерот кој има улога на соговорник со модулот, асоцијацијата на поединци со сите улоги може да биде тешко. Во мала компанија, едно лице може да игра повеќе улоги, додека во голема компанија може да има повеќе луѓе кои имаат единствена улога.
Се чини поразумно да се идентификуваат улогите, наместо луѓето или корисниците.
Затоа:
Ајде да видиме неколку примери
Да претпоставиме дека имаме класа Книга што ги содржи концептот на книга и нејзината функционалност.
класа Книга {
функција getTitle () {
вратете „Одлична книга“;
}
функција getAuthor () {
вратете го „Алесандро Барико“;
}
функција на следната страница () {
// Следна Страна
}
функција за печатење Тековна страница () {
ехо „содржина на тековната страница“;
}
}
Ова е многу нормална класа. Имаме книга, а часот може да ни го даде насловот, тие да ни го дадат авторот и да продолжат понатаму. Конечно, тој е исто така способен да ја печати тековната страница на екранот.
Сепак, постои мал проблем.
Размислувајќи за актерите вклучени во управувањето со објектот Книга, кои би можеле да бидат тие?
Лесно можеме да помислиме на двајца различни актери тука: Управување со книги (како библиотекар) И Механизам за доставување податоци (како тоа како сакаме да му доставиме содржина на корисникот: на екранот, графички кориснички интерфејс, кориснички интерфејс само за текст, можеби и печатење).
Затоа, имаме двајца многу различни актери кои комуницираат со часот.
Накратко, оваа класа се меша помеѓу:
ова може да биде проблем затоа што го крши принципот на единствена одговорност (СРП).
Како можеме да се промениме, како можеме да го подобриме овој кодекс за да го почитуваме принципот на единствена одговорност?
Погледнете го следниот код:
класа Книга {
функција getTitle () {
вратете „Океано Маре“;
}
функција getAuthor () {
вратете го „Алесандро Барико“;
}
функција за свртување страница () {
// Следна Страна
}
функција getCurrentPage () {
ехо „содржина на тековната страница“;
}
}
интерфејс печатач {
функција за печатење Страна ($ страница);
}
класа StampaLibro спроведува печатач {
функција за печатење страници ($ страница) {
ехо $ страница;
}
}
класа HtmlPrinter спроведува печатач {
функција за печатење страници ($ страница) {
ехо ' ' страница $. ' ';
}
}
Овој многу едноставен пример покажува како да се оддели презентацијата од деловната логика, а во согласност со СРП нуди големи предности во флексибилноста на нашиот проект.
Да разгледаме друг пример:
Пример сличен на горенаведениот е кога некој предмет може да заштеди и да се извлече од презентацијата.
класа Книга {
функција getTitle () {
вратете „Океано Маре“;
}
функција getAuthor () {
вратете го „Алесандро Барико“;
}
функција за свртување страница () {
// Следна Страна
}
функција getCurrentPage () {
вратете ја „содржината на тековната страница“;
}
функција зачувување () {
$ filename = '/ документи /'. $ ова-> getTitolo (). '-'. $ ова-> getAuthor ();
file_put_contents ($ name of file, serialize ($ this));
}
}
Како и порано, и тука можеме да идентификуваме различни актери, како што е Управување со книги (како библиотекар) И упорност. Кога и да сакаме да го смениме начинот на кој одиме од страница на страница, треба да ја смениме оваа класа. Можеме да имаме неколку причини за промена.
класа Книга {
функција getTitle () {
вратете „Океано Маре“;
}
функција getAuthor () {
вратете го „Алесандро Барико“;
}
функција за свртување страница () {
// Следна Страна
}
функција getCurrentPage () {
вратете ја „содржината на тековната страница“;
}
}
класа SimpleFilePersistence {
функција зачувај (Резервирај $ книга) {
$ filename = '/ документи /'. $ книга-> getTitle (). '-'. $ книга-> getAuthor ();
file_put_contents ($ name of file, serialize ($ book));
}
}
Преместувањето на операцијата за упорност во друга класа јасно ќе ги оддели одговорностите и ќе можеме слободно да разменуваме методи на упорност без да влијаеме на нашиот час на Книга. На пример, спроведувањето на класата DatabasePersistence би било тривијално, а нашата деловна логика изградена околу работењето на книги нема да се промени.
Продолжете да го читате вториот принцип Отворено / затворено ->
Ercole Palmeri
Ларавел, познат по својата елегантна синтакса и моќните карактеристики, исто така обезбедува цврста основа за модуларна архитектура. Таму…
Cisco и Splunk им помагаат на клиентите да го забрзаат своето патување до Центарот за безбедносни операции (SOC) на иднината со…
Ransomware доминира во вестите во последните две години. Повеќето луѓе се свесни дека нападите…
Операција на офталмопластика со помош на комерцијалниот прегледувач на Apple Vision Pro беше извршена во поликлиниката Катанија…
Развивањето на фини моторни вештини преку боење ги подготвува децата за посложени вештини како пишување. Да обои…
Поморскиот сектор е вистинска глобална економска сила, која навигираше кон пазар од 150 милијарди ...
Минатиот понеделник, Financial Times објави договор со OpenAI. ФТ го лиценцира своето новинарство од светска класа…
Милиони луѓе плаќаат за стриминг услуги, плаќајќи месечна претплата. Општо е мислењето дека вие…
