SOLID, якія 5 прынцыпаў аб'ектна-арыентаванага праграмавання

Цвёрдыя цвёрдыя геаметрычныя фігуры
навучанне
1

SOLID - гэта абрэвіятура, якая спасылаецца на пяць прынцыпаў аб'ектна-арыентаванага дызайну (OOD або OOP). Гэта рэкамендацыі, якія распрацоўшчыкі могуць выкарыстоўваць для стварэння праграм, простымі ў кіраванні, абслугоўванні і пашырэнні. Разуменне гэтых паняццяў зробіць вас лепшым распрацоўшчыкам і дапаможа пазбегнуць праблем з кіраваннем праграмным забеспячэннем. Што значыць быць добрым праграмістам?

Любы чалавек, які мае пэўны вопыт у праграмаванні праграмнага забеспячэння, судзіць аб праграмным кодзе, напісаным іншымі, з выкарыстаннем параметраў меркавання, заснаваных на іх кар'ерным шляху.

На працягу сваёй прафесійнай кар'еры я ведаў шмат распрацоўшчыкаў, бачыў тысячы радкоў кода, і калі мне трэба ацаніць майстэрства распрацоўшчыка, я ў асноўным разглядаю два фактары:

  • Прастата ў чытанні кода;
  • Наколькі верагодна, што іх код будзе працаваць і развівацца з цягам часу.

На шчасце, ёсць некаторыя асновы ці прынцыпы, якія палягчаюць паляпшэнне кадавання.

SOLID абрэвіятура расшыфроўваецца як:
S: прынцып адзінай адказнасці
O: прынцып адкрыта-закрыта
L: Прынцып замены Ліскава
I: Прынцып падзелу інтэрфейсу
D: Прынцып інверсіі залежнасцей

Пачнем з таго, каб паглыбіцца ў першы цвёрды прынцып, а менавіта ў

Прынцып адзінай адказнасці

У класа (альбо модуля) павінна быць толькі адна прычына змяняцца, развівацца.

Сама канцэпцыя вельмі простая, але для дасягнення гэтай прастаты шлях рэалізацыі можа быць вельмі складаным. У класа павінна быць толькі адна прычына змяніцца.

Але чаму? 

Чаму так важна мець толькі адну прычыну, каб змяніцца?

Напрыклад, калі ёсць дзве розныя прычыны для змены, магчыма, дзве розныя каманды могуць працаваць над адным і тым жа кодам па дзвюх розных прычынах. Кожнаму трэба будзе рэалізаваць сваё ўласнае рашэнне, якое ў выпадку скампіляванай мовы (напрыклад, C ++, C # альбо Java) можа прывесці да модуляў, якія несумяшчальныя з іншымі камандамі альбо іншымі часткамі прыкладання.

Іншы прыклад: калі вы выкарыстоўваеце мову з інтэрпрэтацыяй, магчыма, вам прыйдзецца праверыць адзін і той жа клас альбо модуль па розных прычынах. Гэта азначае больш працы, часу і намаганняў для кантролю якасці.

Вызначэнне адной асаблівасці, якую павінен мець клас або модуль, значна больш складанае, чым проста прагляд кантрольнага спісу для запуску тэстаў. 

Але паспрабуем падумаць з менш тэхнічнага пункту гледжання, гэта значыць паспрабуем прааналізаваць карыстальніка нашага класа або модуля, гэта значыць таго, хто будзе ім карыстацца. Фундаментальным аспектам, які мы павінны заўсёды мець на ўвазе, з'яўляецца той факт, што карыстальнікі прыкладання або сістэмы, якія мы распрацоўваем, якія абслугоўваюцца пэўным модулем, будуць тымі, хто запытае яго змены. Служачыя папросяць змяніць клас альбо модуль. 

Некалькі прыкладаў модуляў і іх выкарыстання:

  • Модуль тэхнічнага абслугоўвання: карыстальнік складаецца з адміністратараў баз дадзеных і архітэктараў праграмнага забеспячэння.
  • Модуль справаздачнасці: карыстальнік складаецца з офісных работнікаў, бухгалтараў і вытворчасці.
  • Модуль разліку аплаты для сістэмы кіравання заработнай платай: карыстальнікі могуць ўключаць юрыстаў, менеджэраў і бухгалтараў.
  • Модуль пошуку тэксту для сістэмы кіравання бібліятэкай: карыстальнікі могуць быць прадстаўлены бібліятэкарам альбо наведвальнікамі і кліентамі самой бібліятэкі.

Такім чынам, калі першым крокам з'яўляецца пошук акцёраў або акцёра, які выконвае ролю суразмоўцы з модулем, аб'яднаць асоб з усімі ролямі можа быць цяжка. У невялікай кампаніі адзін чалавек можа гуляць некалькі роляў, у той час як у вялікай кампаніі можа быць некалькі чалавек, якія выконваюць адну ролю. 

Здаецца больш разумным вызначыць ролі, а не людзей і карыстальнікаў.

Таму:

  • карыстальнік праграмнай сістэмы вызначае прычыны змены;
  • адказнасць - гэта сямейства функцый, якое задавальняе патрэбы пэўнага суб'екта, гэта значыць карыстальніка сістэмы;
  • акцёры, карыстальнік становіцца крыніцай зменаў для сямейства функцыянальных магчымасцей, якія павінны задавальняць патрэбы карыстальніка;
  • эвалюцыя патрэб карыстальнікаў, кіруе развіццём функцыянальнасці;

Цвёрдыя прынцыпы

Давайце паглядзім некалькі прыкладаў

Дапусцім, у нас ёсць клас "Кніга", які абагульняе паняцце кнігі і яе функцыянальнасць.

клас Кніга {

    функцыя getTitle () {

        вярнуць "Вялікую кнігу";

    }

    функцыя getAuthor () {

        вярнуць "Алесандра Барыка";

    }

    функцыя nextpage () {

        // наступная старонка

    }

    функцыя printCurrentPage () {

        рэха «змест бягучай старонкі»;

    }

}

Гэта вельмі нармальны клас. У нас ёсць кніга, і клас можа даць нам назву, ён можа даць нам аўтара, і яны могуць рухацца далей. Нарэшце, ён таксама можа друкаваць бягучую старонку на экране. 

Аднак ёсць невялікая праблема. 

Думаючы пра акцёраў, якія ўдзельнічаюць у кіраванні аб'ектам "Кніга", хто яны могуць быць? 

Тут мы можам лёгка падумаць пра двух розных акцёраў: Кіраванне кнігамі (як бібліятэкар) і Механізм падачы дадзеных (напрыклад, як мы хочам даставіць кантэнт карыстальніку: на экране, графічны карыстацкі інтэрфейс, толькі тэкставы карыстацкі інтэрфейс, магчыма, друк) 

Таму ў нас ёсць два вельмі розных акцёра, якія ўзаемадзейнічаюць з класам.

У двух словах, гэты клас стварае сумесь паміж:

  • бізнес-логіка с 
  • прэзентацыя 

гэта можа стаць праблемай, бо парушае прынцып адзінай адказнасці (SRP). 

Як мы можам змяніцца, як мы можам палепшыць гэты кодэкс, каб паважаць прынцып адзінай адказнасці?

Зірніце на наступны код:

клас Кніга {

    функцыя getTitle () {

        вяртанне «Акіяна-кабыла»;

    }

    функцыя getAuthor () {

        вярнуць "Алесандра Барыка";

    }

    функцыя перагортвання старонкі () {

        // наступная старонка

    }

    функцыя getCurrentPage () {

        рэха «змест бягучай старонкі»;

    }

}

інтэрфейс Прынтэр {

    функцыя printPage ($ старонка);

}

клас StampaLibro рэалізуе прынтэр {

    функцыя printPages ($ старонка) {

        рэха $ старонка;

    }

}

 

клас HtmlPrinter рэалізуе Printer {

    функцыя printPages ($ старонка) {

        рэха '. $ старонка. ' ';

    }

}

Гэты вельмі просты прыклад паказвае, як аддзяліць прэзентацыю ад бізнес-логікі, і ў адпаведнасці з SRP ён дае вялікія перавагі ў гнуткасці нашага праекта.

Давайце паглядзім на іншы прыклад:

Прыклад падобны на прыведзены вышэй, калі аб'ект можа захаваць і атрымаць сябе з прэзентацыі.

клас Кніга {

    функцыя getTitle () {

        вяртанне «Акіяна-кабыла»;

    }

    функцыя getAuthor () {

        вярнуць "Алесандра Барыка";

    }

    функцыя перагортвання старонкі () {

        // наступная старонка

    }

    функцыя getCurrentPage () {

        вярнуць "змест бягучай старонкі";

    }

    функцыя save () {

        $ filename = '/ дакументы /'. $ this-> getTitolo (). '-'. $ this-> getAuthor ();

        file_put_contents ($ filename, серыялізаваць ($ this));

    }

}

Як і раней, і тут мы можам вызначыць розных суб'ектаў Кіраванне кнігамі (як бібліятэкар) і Настойлівасць. Кожны раз, калі мы хочам змяніць спосаб пераходу ад старонкі да старонкі, нам трэба змяніць гэты клас. У нас можа быць некалькі прычын для зменаў.

клас Кніга {

    функцыя getTitle () {

        вяртанне «Акіяна-кабыла»;

    }

    функцыя getAuthor () {

        вярнуць "Алесандра Барыка";

    }

    функцыя перагортвання старонкі () {

        // наступная старонка

    }

    функцыя getCurrentPage () {

        вярнуць "змест бягучай старонкі";

    }

}

клас SimpleFilePersistence {

    захаванне функцыі (Book $ book) {

        $ filename = '/ дакументы /'. $ book-> getTitle (). '-'. $ book-> getAuthor ();

        file_put_contents ($ filename, серыялізаваць ($ book));

    }

}

Пераход аперацыі захавання ў іншы клас выразна падзеліць абавязкі, і мы будзем свабодна абменьвацца метадамі захавання, не закранаючы наш клас "Кніга". Напрыклад, рэалізацыя класа DatabasePersistence была б трывіяльнай, і наша бізнес-логіка, пабудаваная вакол кніжных аперацый, не зменіцца.

Працягвайце чытаць другі прынцып Адкрыта / Закрыта ->

1 каментар

пакінуць каментар

Il Tuo indirizzo электроннай пошты ня sarà pubblicato. Я Кампа Соно obbligatori contrassegnati *

ліскавы прынцып
навучанне
Прынцып замены Ліскава, трэці прынцып ЦВЯРДЫ

Дзіцячыя класы ніколі не павінны закранаць ці мяняць азначэнні тыпаў бацькоўскага класа. Паняцце гэтага прынцыпу было ўведзена Барбарай Ліскоў у асноўнай праграме канферэнцыі 1987 г., а затым апублікавана ў артыкуле разам з Джанет Уінг у 1994 г. Іх першапачатковае вызначэнне ...

тэндэнцыі маркетынгу google
навучанне
Як выкарыстоўваць Google Trends для маркетынгу ў рэжыме рэальнага часу

Адной з самых вялікіх цяжкасцей, з якой сутыкнуліся кампаніі ў 2020 годзе, было разуменне, у якіх сектарах прадукцыі дыверсіфікаваць свой бізнес: на самай справе большасць прамысловых сектараў пацярпелі сур'ёзныя наступствы, што робіць практычна немагчымым пранікненне кампаній у іх, асабліва ў якасці новага гульца. Вельмі мала вытворчых сектараў ...

стратэгія бізнес-аналітыкі
метады
Стратэгіі паспяховай бізнес-аналітыкі

Стварэнне паспяховай стратэгіі для вашай бізнес-аналітыкі пачынаецца з правільнага бачання мэтаў. Ніжэй мы бачым некаторыя асноўныя моманты. Ацэнка бягучай сітуацыі Было б сур'ёзнай памылкай недаацэньваць гэты аспект. Ацэнка бягучай сітуацыі азначае аналіз працэсаў, структур ...