Мен SOLID принциптери жөнүндө укпаган иштеп чыгуучуларды көп жолуктурам (биз . — Которуу) же объектиге багытталган программалоо (OOP), же алар жөнүндө уккан, бирок аларды иш жүзүндө колдонбо. Бул макалада иштеп чыгуучуга күнүмдүк ишинде жардам берген OOP принциптеринин артыкчылыктары сүрөттөлөт. Алардын айрымдары белгилүү, башкалары анчалык деле көп эмес, ошондуктан макала башталгычтарга да, тажрыйбалуу программисттерге да пайдалуу болот.
Биз эсиңизге салабыз: бардык Habr окурмандары үчүн - Habr промо-кодун колдонуу менен каалаган Skillbox курсуна катталганда 10 000 рубль арзандатуу.
Skillbox сунуштайт: Онлайн билим берүү курсу .
КУРГАК (Өзүңүздү кайталабаңыз)
Жөнөкөй принцип, анын маңызы атынан көрүнүп турат: "Өзүңдү кайталаба." Программист үчүн бул кайталанма коддон качуу зарылдыгын, ошондой эле өз ишинде абстракцияны колдонуу мүмкүнчүлүгүн билдирет.
Эгерде коддо кайталануучу эки бөлүм болсо, аларды бир ыкмага бириктирүү керек. Катуу коддолгон маани бир нече жолу колдонулса, аны коомдук константага айландыруу керек.
Бул кодду жөнөкөйлөтүү жана тейлөөнү жеңилдетүү үчүн зарыл, бул OOPтун негизги максаты. Бирликти ашыкча колдонбоңуз, анткени бир эле код OrderId жана SSN менен текшерүүдөн өтпөйт.
Өзгөртүүлөрдү капсулдаштыруу
Көпчүлүк компаниялардын программалык продуктылары дайыма өнүгүп турат. Бул кодго өзгөртүүлөрдү киргизүү керек дегенди билдирет, аны колдоо керек. Инкапсуляцияны колдонуу менен жашооңузду жеңилдете аласыз. Бул сизге учурдагы коддук базаңызды натыйжалуураак текшерүүгө жана сактоого мүмкүндүк берет. .
Эгер сиз Java менен жазсаңыз, анда .
Ачык/жабык принцип
Бул принципти төмөнкү билдирүүнү окуу менен оңой эстеп калууга болот: "Программалык камсыздоо объектилери (класстар, модулдар, функциялар ж.б.) кеңейтүү үчүн ачык болушу керек, бирок өзгөртүү үчүн жабык болушу керек." Иш жүзүндө, бул алардын жүрүм-турумун баштапкы кодду өзгөртпөстөн өзгөртүүгө уруксат бере алат дегенди билдирет.
Принцип баштапкы кодго өзгөртүүлөр кодду кайра карап чыгууну, бирдикти текшерүүнү жана башка процедураларды талап кылганда маанилүү. Ачык/жабык принцибине ылайык келген код узартылганда өзгөрбөйт, андыктан аны менен байланышкан көйгөйлөр бир топ азыраак.
Мына ушул принципти бузган кодекстин мисалы.
Эгер андагы бир нерсени өзгөртүү керек болсо, анда ал көп убакытты талап кылат, анткени коддун керектүү фрагмент менен байланышы бар бардык бөлүмдөрүн өзгөртүүгө туура келет.
Айтмакчы, ачыктык-жабыктык СОЛИДдин принциптеринин бири.
Бирдиктүү жоопкерчилик принциби (SRP)
SOLID топтомундагы дагы бир принцип. Анда "класстын өзгөрүшүнө бир гана себеп бар" деп айтылат. Класс бир гана маселени чечет. Анын бир нече ыкмалары болушу мүмкүн, бирок алардын ар бири жалпы көйгөйдү чечүү үчүн гана колдонулат. Бардык ыкмалар жана касиеттер ушуга гана кызмат кылышы керек.
Бул принциптин баалуулугу, ал жеке программалык камсыздоо компоненти менен коддун ортосундагы байланышты бошотот. Эгер класска бирден ашык функцияны кошсоңуз, ал эки функциянын ортосундагы байланышты киргизет. Ошентип, эгер сиз алардын бирин алмаштырсаңыз, биринчиси менен байланышкан экинчисин бузуп алуу мүмкүнчүлүгү жогору. Бул бардык көйгөйлөрдү алдын ала аныктоо үчүн тестирлөө циклдерин көбөйтүүнү билдирет.
Көз карандылыктын инверсия принциби (DIP)
Жогоруда AppManager EventLogWriterге көз каранды болгон коддун мисалы келтирилген, ал өз кезегинде AppManager менен тыгыз байланышта. Эгер сизге эскертмени көрсөтүүнүн башка жолу керек болсо, ал push, SMS же электрондук почта болобу, AppManager классын өзгөртүшүңүз керек.
Көйгөй DIP аркылуу чечилет. Ошентип, AppManagerдин ордуна, алкакты колдонуу менен киргизиле турган EventLogWriter сурайбыз.
DIP көз карандылык модулун өзгөртүү менен айрым модулдарды башкалар менен оңой алмаштырууга мүмкүндүк берет. Бул бир модулду башкаларына таасир этпестен өзгөртүүгө мүмкүндүк берет.
Мурастын ордуна курамы
Кодду кайра колдонуунун эки негизги жолу бар: тукум куучулук жана курамы, экөөнүн тең өз артыкчылыктары жана кемчиликтери бар. Көбүнчө экинчиси ийкемдүү болгондуктан артыкчылык берилет.
Композиция сизге класстын касиеттерин орнотуу менен иштөө учурунда анын жүрүм-турумун өзгөртүү мүмкүнчүлүгүн берет. Интерфейстерди ишке ашырууда полиморфизм колдонулат, бул ийкемдүү ишке ашырууну берет.
Атүгүл Effective Java by Joshua Bloch мураска караганда композицияны тандоону сунуштайт.
Барбара Лисков алмаштыруу принциби (LSP)
SOLID инструменттеринин дагы бир принципи. Анда подтиптер супертипке алмаштырылышы керек деп айтылат. Башкача айтканда, суперкласс менен иштеген методдор жана функциялар анын подкласстары менен көйгөйсүз иштей алышы керек.
LSP бирдиктүү жоопкерчилик принцибине да, жалпы жоопкерчилик принцибине да байланыштуу. Эгерде класс подкласска караганда көбүрөөк функцияны камсыз кылса, анда экинчиси бул принципти бузуп, кээ бир функцияларды колдобойт.
Бул жерде LSPге карама-каршы келген коддун бир бөлүгү.
Аянт(Төрт бурчтук r) ыкмасы тик бурчтуктун аянтын эсептейт. Программа Square аткарылгандан кийин бузулат, анткени Square бул жерде тик бурчтук эмес. LSP принцибине ылайык, базалык класстарга шилтемелерди колдонгон функциялар туунду класстардын объекттерин кошумча көрсөтмөлөрсүз колдоно алышы керек.
Түрчөнүн конкреттүү аныктамасы болгон бул принципти Барбара Лисков 1987-жылы “Маалыматтын абстракциясы жана иерархиясы” деп аталган конференциянын негизги баяндамасында сунуш кылган, ошондуктан анын аталышы.
Interface Separation Principle (ISP)
Дагы бир SOLID принцип. Ага ылайык, колдонулбаган интерфейс ишке ашырылбашы керек. Бул принципти сактоо системанын ийкемдүү жана иштөө логикасына өзгөртүүлөр киргизилгенде рефакторингге ылайыктуу бойдон калууга жардам берет.
Көбүнчө, бул жагдай интерфейс бир эле учурда бир нече функцияларды камтыган учурда пайда болот жана кардар алардын бирөөсүн гана талап кылат.
Интерфейс жазуу кыйын иш болгондуктан, иш аяктагандан кийин эч нерсени бузбай өзгөртүү кыйынга турат.
Javaдагы ISP принцибинин артыкчылыгы бардык методдор биринчи ишке ашырылышы керек, андан кийин гана класстар тарабынан колдонулушу мүмкүн. Ошондуктан, принцип ыкмалардын санын кыскартууга мүмкүндүк берет.
Ишке ашыруу эмес, интерфейс үчүн программалоо
Бул жерде бардыгы аты эле көрүнүп турат. Бул принципти колдонуу интерфейстин каалаган жаңы ишке ашырылышы менен иштей ала турган ийкемдүү кодду түзүүгө алып келет.
Сиз өзгөрмөлөр, кайтаруу түрлөрү же метод аргумент түрү үчүн интерфейс түрүн колдонушуңуз керек. Мисал SubClass эмес, SuperClass колдонуу.
Башкача айтканда:
Тизме номерлери= getNumbers();
Бирок жок:
ArrayList номерлери = getNumbers();
Бул жерде жогоруда айтылгандарды иш жүзүндө ишке ашыруу болуп саналат.
Делегация принциби
Жалпы мисал Java'дагы equals() жана hashCode() методдору. Эки объектти салыштыруу зарыл болгондо, бул аракет кардардын ордуна тиешелүү класска өткөрүлүп берилет.
Принциптин артыкчылыгы - коддун кайталанышы жок жана жүрүм-турумду өзгөртүү салыштырмалуу жөнөкөй. Бул иш-чаранын делегациясына да тиешелүү.
Бул принциптердин баары сизге ийкемдүү, кооз жана ишенимдүү кодду жазууга мүмкүндүк берет, алар жогорку бириктирүү жана аз бириктирүү менен. Албетте, теория жакшы, бирок иштеп чыгуучу алган билимин иш жүзүндө колдонуу үчүн практика керек. OOP принциптерин өздөштүргөндөн кийин, кийинки кадамыңыз программалык камсыздоону иштеп чыгуунун жалпы көйгөйлөрүн чечүү үчүн дизайн үлгүлөрүн үйрөнүү болушу мүмкүн.
Skillbox сунуштайт:
- Практикалык курс .
- Колдонмо онлайн курс .
- Эки жылдык практикалык курс .
Source: www.habr.com