Шаблони за проектиране

1.1 Въведение в моделите

Както бе споменато по-рано, програмистът започва работа по програма, като проектира нейния модел: съставя списък от обекти, върху които програмата ще работи. И колкото повече обекти има в програмата, толкова по-сложна е програмата.

Следователно, за да намалят сложността на програмата, те се опитват да стандартизират взаимодействията на обектите. И това е мястото, където моделите на проектиране or моделите на проектиране помагат много на програмиста . От английски дизайн шаблон .

важно! На руски думата дизайн обикновено означава графичен дизайн, на английски това не е така. Английската дума design е по-близка по meaning до думата „дизайн“ и/or „устройство“. Например, дизайнът на двигателя не е неговият външен вид, а вътрешната му структура.

Следователно моделът на проектиране е точно модел/модел на дизайн. Препоръчвам ви напълно да спрете да използвате думата дизайн в смисъла на „външен вид“. Вие сте бъдещият софтуерен инженер и за вас дизайнът е точно дизайн.

И така, Howъв е този дизайн модел? На първо място, моделът на проектиране е стандартно решение на standardн проблем . Добро, ефективно и изпитано във времето решение.

Да кажем, че сте бor помолени да проектирате велосипед, можете да го направите с две колела, три or дори пет. Така между другото, в зората на дизайна беше така. Но изпитаният във времето подход е на две колела. Но настоящият очевиден подход премина през болка и грешки:

Обикновено шаблонът не е пълно решение, което може директно да се преобразува в code, той е просто пример за добро решение на проблем, който може да се използва в различни ситуации.

Обектно-ориентираните модели показват връзки и взаимодействия между класове or обекти , без да уточняват кои крайни класове or обекти на приложение ще бъдат използвани.

1.2 История на дизайн моделите

През 70-те години програмистите бяха изпequalsи пред необходимостта да разработват големи програми, върху които трябваше да работят цели екипи за разработка. Изпробвани са различни методи за организация на работата, но най-голямо влияние върху развитието оказва строителната индустрия.

За организиране на работата на голяма група хора са използвани практики и подходи от строителния бранш. Между другото, оттам в програмирането навлязоха термини като асемблиране (изграждане), софтуерен разработчик (конструктор) и концепцията за архитектура.

И Howто може би се досещате, идеята за модела на дизайна също е взета от строителната индустрия. Концепцията за модели е описана за първи път от Кристофър Александър в The Pattern Language. градове. Сграда. Строителство“. В тази книга е използван специален език, модели, за описание на процесите на градско проектиране.

Моделите в строителството описват типични изпитани във времето решения: колко високи трябва да бъдат прозорците, колко етажа трябва да има в сградата, колко площ в микрорайона трябва да бъде разпределена за дървета и тревни площи.

Ето защо не е изненадващо, че през 1994 г. книгата „Техники на обектно-ориентирания дизайн. Design Patterns”, който включва 23 шаблона, които решават различни проблеми на обектно-ориентирания дизайн.

Книгата е написана от 4 автора: Ерих Гама, Ричард Хелм, Ралф Джонсън и Джон Влисайдс. Заглавието на книгата беше твърде дълго, за да го запомни някой. Затова скоро всички започнаха да я наричат ​​„книга от бандата от четирима“, тоест „книга от банда от четирима“ , а след това дори „книга на GoF“.

И оттогава са открити други дизайнерски модели. Подходът „модел“ стана популярен във всички области на програмирането, така че сега можете да намерите всяHowви модели извън дизайна на обекти.

важно! Моделите не са няHowви супероригинални решения, а напротив, често срещани, типични решения на един и същи проблем. Добри доказани решения.

1.3 Списък на моделите

Много програмисти не са научor нито един модел през целия си живот, което обаче не им пречи да ги използват. Както казахме преди, шаблоните са добри, изпитани във времето решения и ако програмистът не е глупак, тогава с опит той сам намира такива решения.

Но защо чрез десетки проби и грешки да се стига до оптимални решения, когато има хора, които вече са минали по този път и са написали книги с квинтесенцията на своя опит и житейска мъдрост?

Можете да забиете пирон с гаечен ключ, но защо? Можете дори да използвате бормашина, ако се постараете. Но доброто съзнателно владеене на инструмента е точно това, което отличава професионалиста от аматьора. И професионалистът знае, че основната характеристика на бормашината изобщо не е в това. И така, защо трябва да знаете модели?

• Доказани решения. Прекарвате по-малко време, като използвате готови решения, instead of да изобретявате колелото. Някои решения бихте могли да измислите сами, но много може да са откритие за вас.
• Стандартизация на codeа. Вие правите по-малко грешки при проектирането, като използвате типични унифицирани решения, тъй като всички скрити проблеми в тях отдавна са открити.
• Общ речник по програмиране. Казвате името на модела, instead of да прекарате час в обяснение на други програмисти Howъв страхотен дизайн сте измислor и Howви класове са необходими за това.

Какви са моделите?

Моделите се различават по нивото на сложност, детайлност и покритие на проектираната система. Правейки аналогия със строителството, можете да увеличите безопасността на кръстовището, като поставите светофар, or можете да замените кръстовището с цял автомобилен възел с подлези.

Най-ниските и прости модели са идиоми. Те не са универсални, тъй като са приложими само в рамките на един език за програмиране.

Най-универсалните са архитектурните модели, които могат да бъдат реализирани на почти всеки език. Те са необходими за проектиране на цялата програма, а не на отделни нейни елементи.

Но основното е, че моделите се различават по преднаmeaning. Моделите, с които ще се запознаем, могат да бъдат разделени на три основни групи:

• Моделите за създаване се грижат за гъвкавото създаване на обекти, без да въвеждат ненужни зависимости в програмата.
• Структурните модели показват различни начини за изграждане на връзки между обектите.
• Поведенческите модели се грижат за ефективната комуникация между обектите.

1.4 Въведение в UML

Нека започнем, като разгледаме същите 23 модела, които бяха описани в книгата „Бандата на четиримата“. Както самите модели, така и техните имена са познати неща дори за начинаещ програмист. Ще ви запозная с тях, но силно препоръчвам да прочетете точно тази книга за моделите.

Шаблоните за проектиране не са обвързани с конкретен език за програмиране, така че UML обикновено се използва за тяхното описание. Беше много популярен преди 20 години, но дори и сега понякога се използва. И между другото, описанието на шаблони е само мястото, където използването на UML е стандарт.

С UML можете да описвате връзки между различни обекти. В нашия случай това са обекти и класове.

Връзките между класовете се описват с четири вида стрелки:

	композиция (композиция) - подвид на агрегация, при която "частите" не могат да съществуват отделно от "цялото".
	агрегиране - описва връзката "част" - "цяло", при което "частта" може да съществува отделно от "цялото". Ромбът е обозначен от "цялата" страна.
	зависимост - промяна в един обект (независим) може да повлияе на състоянието or поведението на друг обект (зависим). Независим обект е посочен отстрани на стрелката.
	генерализация - връзката на наследяване or изпълнение на интерфейс. От страната на стрелката е суперкласът or интерфейсът.

Всъщност тук всичко е много просто. Последната стрелка всъщност означава, че един клас е наследен от друг клас. И първата и втората стрелка показват, че един обект съхранява връзка към втория обект. И това е всичко.

Ако диамантът на връзката е черен, тогава връзката е слаба: обектите могат да съществуват един без друг. Ако диамантът е бял, тогава обектите са силно свързани, като например клас HttpRequestи неговия дъщерен клас HttpRequest.Builder.

1.5 Списък на шаблони

Видовете модели ще бъдат обозначени с различни цветове и букви:

б- поведенчески (поведенчески);

° С- генериращи (творчески);

С- структурни (структурни).

И накрая, списък с 23 дизайнерски модела: