Мне даволі часта сустракаюцца распрацоўшчыкі, якія не чулі пра прынцыпы SOLID (мы . - Пер.) Аб'ектна-арыентаванага праграмавання (ААП), або чулі, але не выкарыстоўваюць іх на практыцы. У гэтым артыкуле апісваюцца перавагі прынцыпаў ААП, якія дапамагаюць распрацоўніку ў яго штодзённай працы. Некаторыя з іх добра вядомыя, іншыя – не вельмі, так што артыкул будзе карысны і пачаткоўцам, і ўжо дасведчаным праграмістам.
Нагадваем: для ўсіх чытачоў «Хабра» — зніжка 10 000 рублёў пры запісе на любы курс Skillbox па промакодзе «Хабр».
Skillbox рэкамендуе: Адукацыйны анлайн-курс .
DRY (Don't Repeat Yourself)
Даволі просты прынцып, сутнасць якога зразумелая з назвы: "Не паўтарайся". Для праграміста гэта азначае неабходнасць сыходу ад дублюючага кода, а таксама магчымасць выкарыстоўваць у працы абстракцыю.
Калі ў кодзе ёсць два паўтаральных участку, іх варта аб'яднаць у адзін метад. Калі цвёрда зададзенае значэнне выкарыстоўваецца больш за адзін раз, варта пераўтварыць яго ў агульнадаступную канстанту.
Гэта трэба для таго, каб спрасціць код і зрабіць яго падтрымку прасцей, што з'яўляецца асноўнай задачай ААП. Злоўжываць аб'яднаннем таксама не варта, паколькі адзін і той жа код не мінуе праверку як з OrderId, так і з SSN.
Інкапсуляцыя змен
Праграмныя прадукты большасці кампаній увесь час развіваюцца. Значыць, у код трэба ўносіць змены, яго трэба падтрымліваць. Спрасціць сабе жыццё можна пры дапамозе інкапсуляцыі. Гэта дазволіць больш эфектыўна тэсціраваць і падтрымліваць наяўную базу кода. .
Калі вы пішаце на Java, то .
Прынцып адкрытасці/закрытасці
Гэты прынцып можна лёгка запомніць, прачытаўшы наступнае сцвярджэнне: "Праграмныя сутнасці (класы, модулі, функцыі і да т.п.) павінны быць адчыненыя для пашырэння, але зачыненыя для змены". На практыцы гэта азначае, што яны могуць дазваляць мяняць свае паводзіны без змены зыходнага кода.
Прынцып важны, калі змены ў зыходным кодзе патрабуюць правядзенні яго перагляду, модульнага тэставання і іншых працэдур. Код, які падпарадкоўваецца прынцыпу адкрытасці/закрытасці, не змяняецца пры пашырэнні, таму з ім значна менш праблем.
Вось прыклад кода, які парушае гэты прынцып.
Калі ў ім спатрэбіцца нешта змяніць, на гэта спатрэбіцца шмат часу, паколькі мяняць давядзецца ўсе ўчасткі кода, у якіх ёсць сувязь з патрэбным фрагментам.
Дарэчы, адкрытасць-закрытасць - адзін з прынцыпаў SOLID.
Прынцып адзінай адказнасці (SRP)
Яшчэ адзін прынцып набору SOLID. Ён абвяшчае, што "існуе толькі адна прычына, якая прыводзіць да змены класа". Клас вырашае толькі адну задачу. Ён можа мець некалькі метадаў, але кожны з іх выкарыстоўваецца толькі для рашэння агульнай задачы. Усе метады і ўласцівасці павінны служыць толькі гэтаму.
Каштоўнасць гэтага прынцыпу ў тым, што ён аслабляе сувязь паміж асобным кампанентам праграмнага забеспячэння і кодам. Калі дадаць больш за адну функцыянальнасці ў клас, гэта ўводзіць сувязь паміж двума функцыямі. Такім чынам, калі змяніць адну з іх, вялікі шанец сапсаваць другую, злучаную з першай. А гэта азначае павелічэнне цыклаў тэсціравання для таго, каб выявіць усе праблемы загадзя.
Прынцып інверсіі залежнасцяў (DIP)
Вышэй прыведзены прыклад кода, дзе AppManager залежыць ад EventLogWriter, які, у сваю чаргу, цесна злучаны з AppManager. Калі патрэбен іншы спосаб паказаць апавяшчэнне, няхай гэта будзе пуш, SMS ці email, трэба змяніць клас AppManager.
Праблема можа быць вырашана пры дапамозе DIP. Так, замест AppManager мы запытваем EventLogWriter, які будзе ўведзены пры дапамозе фрэймворка.
DIP дае магчымасць без праблем замяняць асобныя модулі іншымі, змяняючы модуль залежнасці. Гэта дае магчымасць змяняць адзін модуль, не ўплываючы на іншыя.
Кампазіцыя замест атрымання ў спадчыну
Асноўных спосабаў паўторнага выкарыстання кода два - гэта ўспадкоўванне і кампазіцыя, прычым у кожнага ёсць як свае перавагі, так і недахопы. Звычайна перавага аддаецца другому, паколькі ён гнутчэйшы.
Кампазіцыя дае магчымасць змяняць паводзіны класа падчас выканання шляхам усталёўкі яго ўласцівасцяў. Пры рэалізацыі інтэрфейсаў выкарыстоўваецца палімарфізм, які дае больш гнуткую рэалізацыю.
Нават "Effective Java" Джошуа Блох (Joshua Bloch) раіць аддаваць перавагу кампазіцыі, а не ўспадкоўванню.
Прынцып падстаноўкі Барбары Ліскаў (LSP)
Яшчэ адзін прынцып з інструментара SOLID. Ён абвяшчае, што падтыпы павінны быць заменнымі для супертыпу. Гэта значыць метады і функцыі, якія працуюць з суперкласам, павінны мець магчымасць без праблем працаваць і з яго падкласамі.
LSP звязаны як з прынцыпам адзінай адказнасці, так і з прынцыпам падзелу адказнасці. Калі клас дае больш функцыянальнасці, чым падклас, то апошні не будзе падтрымліваць некаторыя функцыі, парушаючы гэты прынцып.
Вось участак кода, які супярэчыць LSP.
Метад area (Rectangle r) пралічвае плошчу Rectangle. Праграма ўпадзе пасля выканання Square, паколькі Square тут не з'яўляецца Rectangle. Згодна з прынцыпам LSP, функцыі, якія выкарыстоўваюць спасылкі на базавыя класы, павінны мець магчымасць выкарыстоўваць і аб'екты вытворных класаў без дадатковых інструкцый.
Гэты прынцып, які з'яўляецца спецыфічным вызначэннем падтыпу, быў прапанаваны Барбарай Ліскаў у 1987 годзе на канферэнцыі ў асноўным дакладзе пад назвай "Абстракцыя даных і іерархія" — адсюль і яго назва.
Прынцып падзелу інтэрфейсу (ISP)
Чарговы прынцып SOLID. Згодна з ім інтэрфейс, які не выкарыстоўваецца, не павінен быць рэалізаваны. Прытрымліванне гэтага прынцыпу дапамагае сістэме заставацца гнуткай і прыдатнай для рэфактарынгу пры занясенні змен у логіку працы.
Часцей за ўсё гэтая сітуацыя адбываецца, калі інтэрфейс утрымоўвае адразу некалькі функцыянальнасцяў, прычым кліенту патрэбна толькі адна з іх.
Паколькі напісанне інтэрфейсу - складаная задача, пасля завяршэння працы змяніць яго, нічога не парушыўшы, будзе праблемай.
Вартасцю прынцыпу ISP у Java з'яўляецца тое, што спачатку трэба рэалізаваць усе метады, і толькі потым яны могуць быць скарыстаны класамі. Таму прынцып дае магчымасць зменшыць колькасць метадаў.
Праграмаванне для інтэрфейсу, а не рэалізацыі
Тут усё зразумела з назвы. Ужыванне гэтага прынцыпу вядзе да стварэння гнуткага кода, які зможа працаваць з любой новай рэалізацыяй інтэрфейсу.
Варта выкарыстоўваць тып інтэрфейсу для зменных, якія вяртаюцца тыпаў ці ж тыпу аргументу метаду. Прыклад - выкарыстанне SuperClass, а не SubClass.
Гэта значыць:
List numbers= getNumbers();
А не:
ArrayList numbers = getNumbers();
Вось практычная рэалізацыя таго, аб чым гаворыцца вышэй.
Прынцып дэлегавання
Распаўсюджаны прыклад - метады equals() і hashCode() у Java. Калі патрабуецца параўнаць два аб'екты, тое гэта дзеянне дэлегуецца які адпавядае класу замест кліенцкага.
Перавагай прынцыпу з'яўляецца адсутнасць дубліравання кода і адносна простая змена паводзін. Таксама ён дастасоўны да дэлегавання падзей.
Усе гэтыя прынцыпы дазваляюць пісаць больш гнуткі, прыгожы і надзейны код з высокай складнасцю і нізкім зачапленнем. Вядома, тэорыя - гэта добра, але каб распрацоўшчык сапраўды стаў выкарыстоўваць атрыманыя веды, патрэбна практыка. Наступным крокам пасля засваення прынцыпаў ААП можа стаць вывучэнне шаблонаў праектавання для рашэння агульных праблем распрацоўкі ПЗ.
Skillbox рэкамендуе:
- Практычны курс .
- Прыкладны анлайн-курс .
- Двухгадовы практычны курс .
Крыніца: habr.com