Шаблони за проектиране в Java [част 1]

Това е кратка статия за дизайнерски модели в Java. Няма да има реализации на шаблони, а само списък с шаблони в Java заедно с кратко описание на всеки. За тези, които вече са запознати с темата, това ще бъде полезно като преглед и резюме. Обратно, тези, които научават за моделите за първи път, ще се възползват от това като първоначален преглед на темата, преди да копаят по-дълбоко. Шаблони за проектиранеса готови за използване решения за често срещани програмни задачи. Това не е клас or библиотека, която може да бъде свързана с проект. Това е нещо повече. Във всеки конкретен случай се изпълняват шаблони за проектиране, подходящи за всяка задача. Трябва да запомните, че когато се прилага неправилно or към неподходяща задача, моделът на дизайн може да създаде много проблеми. Въпреки това, правилно приложен шаблон може да ви помогне да изпълнявате задачите лесно и просто.

Видове модели:

• сътворителен
• структурен
• поведенчески

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

Творчески:

• Singleton — ограничава създаването на клас до единичен екземпляр и предоставя достъп до този единичен екземпляр.

• Фабрика — използва се, когато имаме суперклас с множество подкласове и трябва да върнем подклас въз основа на вход.

• Абстрактна фабрика — използва супер фабрика за създаване на фабрики, които след това използваме за създаване на обекти.

• Builder — използва се за създаване на сложни обекти с помощта на прости обекти. Той постепенно създава голям обект от малък, прост обект.

• Прототип — помага за подобряване на производителността при създаване на дублирани обекти; instead of да създава нов обект, той създава и връща клонинг на съществуващ обект.

Структурни:

• Адаптер — преобразувател между два несъвместими обекта. Можем да използваме модела на адаптера, за да комбинираме два несъвместими интерфейса.

• Composite — използва един клас за представяне на дървовидна структура.

• Прокси — осигурява функционалността на друг клас.

• Flyweight — повторно използване на обекти instead of създаване на голям брой подобни обекти.

• Фасада — осигурява прост интерфейс за клиент, който използва интерфейса за взаимодействие със системата.

• Bridge — прави специфични класове независими от класовете, изпълняващи интерфейс.

• Декоратор — добавя нова функционалност към съществуващ обект, без да се обвързва със структурата му.

Поведенчески:

• Шаблонен метод — дефинира основен алгоритъм и позволява на наследниците да заменят някои стъпки от алгоритъма, без да променят цялостната му структура.

• Посредник — осигурява междинен клас, който обработва цялата комуникация между различни класове.

• Верига на отговорност — дава възможност да се избегне строгата зависимост между подателя и получателя на заявка; освен това заявката може да бъде обработена от няколко обекта.

• Наблюдател — позволява на един обект да наблюдава и да реагира на събития, възникващи в други обекти.

• Стратегия — позволява стратегиите (алгоритмите) да бъдат променяни по време на изпълнение.

• Команда — интерфейс, който декларира метод за извършване на конкретно действие.

• Състояние — позволява на обекта да променя поведението си в зависимост от състоянието си.

• Посетител — използва се за опростяване на операциите върху групи от свързани обекти.

• Интерпретатор — дефинира граматика за прост език в проблемната област.

• Итератор — последователно осъществява достъп до елементи от колекция, без да знае нейната основна форма.

• Memento — използва се за съхраняване на състоянието на обект; това състояние може да бъде възстановено по-късно.

Докато преминавате през курса на CodeGym, ще срещнете няколко модела в този списък. Препоръчвам следните задачи за шаблони: 1522 , 1530 , 1631 , big01 , 2912 , 3107 ... Разумното използване на шаблони за проектиране води до по-надеждна поддръжка на codeа, защото в допълнение към факта, че шаблоните за проектиране са добри решения на общи проблеми , други разработчици могат да ги разпознаят, намалявайки времето, необходимо за работа с определен code.