3.1 Сингълтън
Singleton е общ модел на проектиране, който гарантира, че еднонишково приложение ще има един екземпляр от няHowъв клас и осигурява глобална точка за достъп до този екземпляр.
Много често начинаещите програмисти обичат да събират помощни методи в няHowъв статичен клас - клас, който съдържа само статични методи. Този подход има редица недостатъци - например не можете да подадете препратка към обект от такъв клас, такива методи са трудни за тестване и други подобни.
Като алтернатива беше предложено решение за единичен клас: клас, който може да има само един обект. Когато се опитвате да създадете този обект, той се създава само ако все още не съществува, в противен случай се връща препратка към вече съществуващ екземпляр.
От съществено meaning е да е възможно да се използва екземпляр на класа, тъй като в много случаи става достъпна по-широка функционалност. Например, този клас може да реализира някои интерфейси и неговият обект може да бъде предаден на други методи като имплементация на интерфейса. Какво не може да се направи с набор от статични методи.
Професионалисти:
- Методите са обвързани с обект, а не със статичен клас - можете да предадете обект по референция.
- Обектните методи са много по-лесни за тестване и подиграване.
- Обект се създава само когато е необходимо: мързелива инициализация на обект.
- Ускоряване на първоначалното стартиране на програмата, ако има много сингъли, които не са необходими за стартиране.
- Сам по себе си може допълнително да се превърне в шаблонна стратегия or няколко такива обекта.
минуси:
- Става по-трудно да се контролират състезанията и забавянията между нишките.
- Трудно е да се напише многопоточен „самотник“ „от главата“: достъпът до дългогодишен сингълтон в идеалния случай не трябва да отваря мютекс. По-добри доказани решения.
- Конфликт между две нишки заради незавършена единична нишка ще доведе до забавяне.
- Ако обектът се създава дълго време, забавянето може да попречи на потребителя or да наруши реалното време. В този случай е по-добре да прехвърлите създаването му на етапа на инициализация на програмата.
- Необходими са специални функции за тестване на единици - например, за да поставите библиотеката в режим „несамотен“ и напълно да изолирате тестовете един от друг.
- Необходима е специална тактика за тестване на готовата програма, защото дори концепцията за „най-простата възможност за стартиране“ изчезва, тъй като възможността за стартиране зависи от конфигурацията.
3.2 Фабрика [Метод]
Фабричен метод е общ модел на проектиране, който предоставя на подкласове (класове-наследници) интерфейс за създаване на екземпляри на определен клас. По време на създаването потомците могат да определят кой клас да бъде създаден.
С други думи, този шаблон делегира създаването на обекти на потомците на родителския клас. Това ви позволява да използвате не конкретни класове в програмния code, а да манипулирате абстрактни обекти на по-високо ниво.
Този модел дефинира интерфейс за създаване на обект, но оставя на подкласовете да решат на кой клас да базират обекта. Фабричен метод позволява на клас да делегира създаването на подкласове. Използва се, когато:
- класът не знае предварително кои обекти от кои подкласове трябва да създаде.
- класът е проектиран така, че обектите, които създава, да са определени от подкласове.
- класът делегира своите отговорности на един от няколко помощни подкласа и се планира да се определи кой клас поема тези отговорности.
3.3 Абстрактна фабрика
Абстрактната фабрика е общ дизайн модел, който предоставя интерфейс за създаване на семейства от свързани or взаимозависими обекти, без да се уточняват техните конкретни класове.
Моделът е имплементиран чрез създаване на абстрактен клас Factory, който е интерфейс за създаване на системни компоненти (например за интерфейс на прозорец може да създава прозорци и бутони). След това се пишат класове, които реализират този интерфейс.
Използва се в случаите, когато програмата трябва да бъде независима от процеса и типовете на създаваните нови обекти. Когато е необходимо да се създадат семейства or групи от свързани обекти, като се изключи възможността за едновременно използване на обекти от различни набори от тях в един и същи контекст.
Силни страни:
- изолира специфични класове;
- опростява подмяната на фамorите продукти;
- гарантира съвместимост на продукта.
Да приемем, че вашата програма работи с файловата система. След това, за да работите в Linux, ви трябват обекти LinuxFile, LinuxDirectory, LinuxFileSystem. А за да работите в Windwos, имате нужда от класовете WindowsFile, WindowsDirectory, WindowsFileSystem.
Класът Path, който се създава чрез Path.of(), е точно такъв случай. Path всъщност не е клас, а интерфейс и има реализации на WindowsPath и LinuxPath. И Howъв вид обект ще бъде създаден е скрит от вашия code и ще бъде решен по време на изпълнение.
3.4 Прототип
Прототипът е генеративен дизайн модел.
Този шаблон дефинира видовете обекти, които се създават с помощта на екземпляр на прототип и създава нови обекти чрез копиране на този прототип. Това ви позволява да се измъкнете от внедряването и да следвате принципа на „програмиране чрез интерфейси“.
Интерфейс/абстрактен клас в горната част на йерархията е посочен като връщащ тип и класовете потомци могат да заменят наследник, който имплементира този тип там. Просто казано, това е моделът за създаване на обект чрез клониране на друг обект, instead of да го създавате чрез конструктор.
Шаблонът се използва за:
- избягване на допълнителните усorя за създаване на обект по standardн начин (което означава използване на конструктор, тъй като в този случай конструкторите на цялата йерархия на предшественика на обекта също ще бъдат извикани), когато това е непосилно скъпо за приложението.
- избягвайте наследяването на създателя на обекта в клиентското приложение, Howто прави абстрактният фабричен модел.
Използвайте този модел на проектиране, когато вашата програма не се интересува How създава, композира и представя продукти:
- инстанцираните класове се определят по време на изпълнение, например чрез използване на динамично зареждане;
- искате да избегнете изграждането на йерархии на класове or фабрики, които са успоредни на йерархията на продуктовите класове;
- екземплярите на класа могат да бъдат в едно от няколко различни състояния. Може да е по-удобно да зададете подходящия брой прототипи и да ги клонирате, instead of ръчно да инстанциирате класа в подходящото състояние всеки път.