JavaRush /Курстар /All lectures for KY purposes /Дизайн паттерндор

Дизайн паттерндор

All lectures for KY purposes
Деңгээл , Сабак
жеткиликтүү

1.1 Паттерндер менен таанышуу

Мурда айтылгандай эле, программист программа менен ишти баштаганда анын моделин долбоорлонуу менен баштайт: программанын иштөөчү объекттеринин тизмегин түзүү. Жана программасында канча көп объект болсo, ал программа ошончолік татаал болот.

Ошондуктан программадагы татаалдыктарды азайтуу үчүн, объекттердин өз ара аракеттешүүсүн стандартташтырууга аракет кылышат. Бул жагынан программистке абдан жардам берет дизайн шаблондору же паттерндер. Англисче design pattern.

Маанилүү! Орусча тилде дизайн дегенибизде, көп учурда графикалык дизайн дегенди түшүнөбүз, англис тилинде андай эмес. Англисче design сөзү "долбоорлонуу" жана/же "түзүлүш" дегенге жакын. Мисалы, двигательдин дизaйны дегенде анын көрүнүшү эмес, анын ички түзүлүшү болот.

Ошондуктан design pattern - бул так эле долбоорлонуу паттерни. Дизайнды "сырткы көрүнүш" деген маанини колдонгондо таптакыр токтотууну сунуштайм. Сен келечектеги Software Engineerсиң, жана сен үчүн дизайн бул - долбоорлоо.

Эмесе, design pattern деген эмне? Алгач, долбоорлоо паттерни бул стандарттык проблема үчүн стандарттык чечим. Жакшы, натыйжалуу жана убакыттын сыноосунан өткөн чечим.

Мисалы, сага велосипед долбоорлоону беришти, сен ага эки, үч же беш дөңгөлөк жасай аласың. Чынында, долбоорлоо баштапкы учурларында ушундай болгон. Бирок убакыт сыноосунан өткөн ыкма - эки дөңгөлөк. Учурдагы жандуу ыкмага тагыракка жетүү үчүн көптөгөн ката жана оорулар аркылуу келишкен:

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

Объектүүгө багытталган шаблондор класстар же объекттер ортосундагы өз ара аракеттешүүлөрдү көрсөтөт, кайсы акыркы класстар же объекттер колдонуларын аныктабай эле.

1.2 Дизайн паттерндердин тарыхы

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

Көп сандаган адамдардын иштерин уюштуруу үчүн курулуш чөйрөсүнөн практикалар жана ыкмалар колдонулган. Мындан тышкары, программалоого "сборка" (build), Software Developer (куруучу), жана архитектура деген түшүнүктөр ошол жактан келген.

:оошондуктан design pattern идеясы да курулуштан келди. Концепцияны Кристофер Александер "Язык шаблонов. Города. Здания. Строительство" аттуу китебинде биринчи жолу сүрөттөгөн болчу. Ал китепте шаардын долбоорлоо процесстерин сүрөттөө үчүн өзгөчө тил - паттерндер колдонулган.

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

Ошондуктан 1994-жылы "Приемы объектно-ориентированного проектирования. Паттерны проектирования" китеби чыкканына эч таң калбайбыз, бул китепте объектно-ориентированного дизайнда ар кандай маселелерди чечкен 23 паттерн бар болгон.

Бул китепти 4 автор жазган: Эрих Гамма, Ричард Хелм, Ральф Джонсон жана Джон Влиссидес. Китептин аталышы өтө узак болгондуктан, аны баары "book by the gang of four", демек "төрттүн тобунун китеби", кийинчерээк "GoF book" деп атап кеткен.

Ошол мезгилден бери башка дизайн паттерндеринин дагы ачылышы болду. "Паттерндердин" ыкмасы программалоонун бардык чөйрөлөрүндө популярдуу болуп калды, ошондуктан азыр объектно-ориентированного долбоордун сыртында дагы ар кандай паттерндерди кездештирүүгө болот.

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

1.3 Паттерндердин тизмеги

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

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

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

  • Текшерилген чечимдер. Сен убакытты аз коротосуң, даяр чечимдерди колдонуп, кайра велосипед ойлоп таппайсың. Айрым чечимдерди өзүң ойлоп табасың, бирок көптөгөн чечимдер сага ачылыш болушу мүмкүн.
  • Кодду стандартташтыруу. Сен долбоорлоо учурунда аз каталар кетиресиң, типтүү бирдиктүү чечимдерди колдонуп, анда жашыруун маселелер мурунтан ачылган.
  • Жалпы программисттердин сөздүгү. Сен паттерн аталышын айтасың, анын ордуна сааттарча башка программисттерге кандай сонун дизайн ойлоп тапканыңды жана кандай класстар керек экенин түшүндүрүүнүн ордуна.

Паттерндердин түрлөрү кайсылар?

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

Эң төмөнкү жана жөнөкөй паттерндер — идиомалар. Алар универсалдуу эмес, анткени алар бир гана программалоо тилинде колдонулат.

Эң универсалдуу — архитектуралык паттерндер, аларды каалаган тилде ишке ашырса болот. Алар бүткүл программаны долбоорлоо үчүн керек, анын айрым элементтерин эмес.

Бирок эң негизгиси — паттерндер максаты боюнча айырмаланат. Биз тааныш болгон паттерндерди үч негизги топко бөлө алабыз:

  • Жаратылуучу паттерндер объекттерди ийкемдүү түзүү менен программаны керексиз байланыштардан сактайт.
  • Структуралык паттерндер объекттер ортосундагы байланыштарды түзүүнүн ар кандай ыкмаларын көрсөтөт.
  • Мүнөздүү паттерндер объекттер ортосунда натыйжалуу байланыштарды түзүү менен кам көрөт.

1.4 UML менен таанышуу

Төртүнчүнүн тобунун китебинде сүрөттөлгөн 23 паттернди карап чыгууну баштайбыз. Паттерндер да, алардын аттары да программисттер үчүн тааныш нерселер. Мен сени менен тааныштырам, бирок ошол эле китепти окууга кеңеш берем.

Дизайн паттерндер конкреттүү программалоо тилине байланган эмес, андыктан аларды сүрөттөө үчүн көбүнчө UML тили колдонулат. Ал 20 жыл мурун абдан популярдуу болгон, бирок азыр да кээде колдонулат. Жана, айтмакчы, паттерндерди сүрөттөө — бул кыскача айтканда, UML колдонуу стандарты.

UML менен сен ар кандай объекттер ортосундагы өз ара байланыштарды сүрөттөй аласың. Биздин учурда — бул объекттер жана класстар.

Класстар ортосундагы байланыштар төрт түрдүү жебелер менен сүрөттөлөт:

композиция (composition) — агрегациянын бир түрү, анда "бөлүктөр" "бүтүн" жокто өз алдынча боло албайт.
агрегация (aggregation) — "бөлүк" – “бүтүн” байланышын сүрөттөйт, анда "бөлүк" "бүтүн" жокто өз алдынча боло алат. Ромб "бүтүндүн" тарабында көрсөтүлгөн.
зависимость (dependency) — бир объектте (өз алдынчасы) болгон өзгөртүү экинчи объекттин (зависимдин) абалына же жүрүшүнө таасир этет. Жебенин тарабында көз карандысыз объект көрсөтүлгөн.
обобщение (generalization) — мурастоо же интерфейсти ишке ашыруу байланышы. Жебенин тарабында суперкласс же интерфейс турат.

Чынында, баары өтө жөнөкөй. Акыркы жебе, чындыгында, бир класстын башка класстан мурасталган экенин көрсөтөт. Биринчи жана экинчи жебе - бул бир объект экинчи объектке шилтеме сактаганын билдирет. Бул баары.

Эгер ромб ак болсо, шилтеме алсыз: объекттер бир-бирисиз боло алат. Эгер ромб кара болсо, объекттер күчтүү байланышкан, мисалы, HttpRequest классы жана анын туунду HttpRequest.Builder классы.

1.5 Паттерндердин тизмеги

Паттерндердин түрлөрүн ар кандай түстөр менен жана тамгалар менен белгилейбиз:

B — мүнөздүү (behavioral);

C — жаратылуучу (creational);

S — структуралык (structural).

Жана акыры 23 дизайн паттерндеринин тизмеги:

C — Абстрактная фабрика

S — Адаптер

S — Мост

C — Строитель

B — Цепочка обязанностей

B — Команда

S — Компоновщик

S — Декоратор

S — Фасад

C — Фабричный метод

S — Приспособленец

B — Интерпретатор

B — Итератор

B — Посредник

B — Хранитель

C — Прототип

S — Прокси

B — Наблюдатель

C — Одиночка

B — Состояние

B — Стратегия

B — Шаблонный метод

B — Посетитель

Комментарийлер
TO VIEW ALL COMMENTS OR TO MAKE A COMMENT,
GO TO FULL VERSION