SOLID объектке багытталган программалоонун 5 принциби кандай

Катуу геометриялык фигуралар
үйрөтүү
1

SOLID - аббревиатура, объектке багытталган дизайндын беш принцибине (OOD же OOP) таандык. Бул иштеп чыгуучулар колдонуп, башкарууга, тейлөөгө жана кеңейтүүгө оңой программаны түзүүдө колдоно алышат. Бул түшүнүктөрдү түшүнүү сизди мыкты иштеп чыгуучуга айлантат жана программалык камсыздоону башкаруу көйгөйлөрүнөн алыс болууга жардам берет. Жакшы программист болуу деген эмнени билдирет?

Программалык камсыздоону тажрыйбасы бар адам, башкалар тарабынан жазылган программалык кодду, алардын мансаптык жолунун негизинде соттун параметрлерин колдонот.

Кесиптик карьерамдын жүрүшүндө мен көптөгөн иштеп чыгуучуларды билдим жана миңдеген коддорду көрдүм жана иштеп чыгуучунун чеберчилигин баалоо керек болгондо мен негизинен эки факторду карадым:

  • Кодду окуудагы жөнөкөйлүк;
  • Убакыттын өтүшү менен алардын коду иштеши жана өнүгүшү канчалык ыктымал.

Бактыга жараша, кээ бир негиздери же принциптери бар, бул кодирование мыкты болууга жардам берет.

SOLID аббревиатурасы:
S: бирдиктүү жоопкерчилик принциби
O: ачык-жабык принцип
L: Лисковду алмаштыруу принциби
I: Интерфейсти бөлүү принциби
D: Көзкарандылыктарды инверсиялоо принциби

Биринчи SOLID принцибине, тактап айтканда

Жалгыз жоопкерчилик принциби

Класстын (же модулдун) өзгөрүшүнө, өнүгүшүнө бир гана себеби болушу керек.

Концепциянын өзү өтө жөнөкөй, бирок ушул жөнөкөйлүккө жетүү үчүн, ишке ашыруу жолу өтө татаал болушу мүмкүн. Классты өзгөртүү үчүн бир гана себеп болушу керек.

Бирок эмне үчүн? 

Эмне үчүн өзгөрүүнүн бир гана себеби болушу керек?

Мисалы, өзгөрүүнүн эки башка себеби бар болсо, эки башка топтун эки башка себептен бир эле код менен иштеши мүмкүн деп божомолдоого болот. Ар бири өз чечимдерин ишке ашырууга аргасыз болот, алар компиляцияланган тилде (мисалы, C ++, C # же Java), башка командаларга же тиркеменин башка бөлүктөрүнө туура келбеген модулдарды алып келиши мүмкүн.

Дагы бир мисал, эгер сиз которулган тилди колдонуп жатсаңыз, анда ар кандай себептерден улам бир эле классты же модулду кайрадан тестирлөөгө туура келет. Бул сапатты көзөмөлдөө үчүн көбүрөөк эмгекти, убакытты жана күчтү талап кылат.

Класстын же модулдун бирден-бир өзгөчөлүгүн аныктоо, тест жүргүзүү үчүн текшерүү тизмесин карап отургандан кыйла татаал. 

Бирок, азыраак техникалык көз караш менен ойлонууга аракет кылалы, башкача айтканда, биздин класстын же модулдун колдонуучусун анализдеп көрөлү, аны ким колдонот. Биз иштеп чыгуучу тиркеменин же тутумдун колдонуучулары белгилүү бир модул тарабынан тейленип, ага өзгөртүүлөрдү киргизүүнү суранган адамдар болушу керек экендигин биз дайыма эсибизден чыгарбашыбыз керек. Кызмат кылгандар классты же модулду өзгөртүүнү суранышат. 

Модулдардын айрым мисалдары жана аларды колдонуу:

  • Техникалык тейлөө модулу: колдонуучу маалыматтар базасынын администраторлорунан жана программалык архитекторлордон турат.
  • Отчеттуулук модулу: колдонуучу кеңсе кызматкерлеринен, бухгалтерлерден жана өндүрүштөн турат.
  • Эмгек акыны башкаруу тутуму үчүн төлөмдү эсептөө модулу: колдонуучуларга юристтер, менеджерлер жана бухгалтерлер кириши мүмкүн.
  • Китепкананы башкаруу тутуму үчүн текст издөө модулу: колдонуучуну китепканачы же китепканага келгендер жана кардарлар көрсөтө алышат.

Демек, биринчи кезекте модул менен маектешкен ролду ойногон актерлорду же актёрлорду издөө керек болсо, анда бардык ролдор менен адамдарды бириктирүү кыйынга турушу мүмкүн. Чакан компанияда бир адам бир нече ролду ойной алат, ал эми ири компанияда бир ролду ойногон бир нече адам болушу мүмкүн. 

Адамдарды же колдонуучуларды эмес, ролдорду аныктоо акылга сыярлык окшойт.

Ошондуктан:

  • программалык тутумдун колдонуучусу өзгөрүүнүн себептерин аныктайт;
  • жоопкерчилик - белгилүү бир актердун, башкача айтканда, тутумдун колдонуучусунун муктаждыктарын канааттандырган функциялардын үй-бүлөсү;
  • актерлор, колдонуучу колдонуучунун керектөөсүн канааттандырышы керек болгон функционалдык үй-бүлөнүн өзгөрүү булагы болуп калат;
  • колдонуучунун муктаждыктарынын эволюциясы, функционалдык эволюцияны жетектейт;

SOLID принциптери

Келгиле, кээ бир мисалдарды карап көрөлү

Бизде китеп түшүнүгү жана анын иштеши камтылган 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 классын ишке ашыруу маанисиз болуп калат жана биздин китеп ишинин тегерегинде курулган бизнес логикабыз өзгөрбөйт.

Ачык / Жабык -> экинчи принцибин окуп улантыңыз

1 комментарий

Комментарий калтыруу

Сиздин электрондук почта дареги жарыяланбайт. Милдеттүү талаалар белгиленген *

лисков принцип
үйрөтүү
Liskov алмаштыруу принциби, үчүнчү SOLID принциби

Бала класстары эч качан ата-эненин классындагы аныктамаларга таасирин тийгизбеши керек. Бул принциптин концепциясын Барбара Лисков 1987-жылдагы конференциянын негизги баяндамасында киргизген жана андан кийин 1994-жылы Жаннет Винг менен бирге макаласында жарыяланган. Алардын баштапкы аныктамасы ...

Google маркетингинин тенденциялары
үйрөтүү
Google Trendsди чыныгы убакыт маркетингинде кантип колдонсо болот

2020-жылы компаниялар дуушар болгон эң чоң кыйынчылыктардын бири - өнүмдөрдүн кайсы тармактары өз бизнесин диверсификациялоону түшүнүү болгон: иш жүзүндө көпчүлүк өнөр жай тармактары оор кесепеттерге дуушар болуп, ишканаларга кирүү дээрлик мүмкүн болбой калды, айрыкча жаңы оюнчу катары. Өндүрүш тармактары өтө эле аз ...

ишкердик чалгындоо стратегиясы
методдору
Ийгиликтүү бизнес-интеллект стратегиялары

Business Intelligence үчүн ийгиликтүү стратегияны түзүү максаттарды туура көрүүдөн башталат. Төмөндө айрым негизги ойлорду көрөбүз. Учурдагы кырдаалга баа берүү Ушул өңүттү баалабай коюу чоң жаңылыштык болот. Учурдагы кырдаалды баалоо дегенибиз процесстерди, структураларды талдоо ...