7-те най-важни модела на дизайн на софтуера

За цялостно задълбочено навлизане в темата за моделите на дизайн на софтуер, разгледайте Шаблони за дизайн на софтуер: Най-добри практики за разработчици, създадени от C.H. Afzal, ветерански софтуерен инженер с многогодишен опит в Netflix, Microsoft и Oracle. Голяма част от по-долу е обобщена от неговия курс.

Защо шаблони за дизайн?

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

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

Фактът обаче остава, че дизайнерските модели могат да бъдат невероятно полезни, ако се използват в правилните ситуации и по правилните причини. Когато се използват стратегически, те могат да направят програмист значително по-ефективен, като им позволят да избегнат изобретяването на пословичното колело, вместо това да използват методи, усъвършенствани от други. Те също така предоставят полезен общ език за концептуализиране на повтарящи се проблеми и решения при обсъждане с други или управление на код в по-големи екипи.

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

Без допълнително обожание (в общ ред по важност, от повечето до най-малкото):

Най-важните модели на дизайн

  1. сек

Singleton моделът се използва за ограничаване създаването на клас само до един обект. Това е от полза, когато за координиране на действия в системата е необходим един (и само един) обект. Има няколко примера за това, когато трябва да съществува само един екземпляр от клас, включително кешове, пулове от нишки и регистри.

Тривиално е да инициирате обект от клас, но как да гарантираме, че само един обект някога се създава? Отговорът е да направим конструктора „частен“ за класа, който възнамеряваме да определим като сингълтон. По този начин само членовете на класа могат да имат достъп до частния конструктор и никой друг.

Важно съображение: Възможно е да се подкласира сингълтон, като конструкторът бъде защитен вместо частен. Това може да е подходящо при някои обстоятелства. Един подход, използван в тези сценарии, е да се създаде регистър на единични бутони на подкласовете и методът getInstance може да приеме параметър или да използва променлива среда, за да върне желания сингълтон. След това системният регистър поддържа картографиране на имена на низове към единични обекти, до които може да се достигне при необходимост.

2. Фабричен метод

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

Обикновено създаването на обекти в Java се извършва така:

SomeClass someClassObject = нов SomeClass ();

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

3. Стратегия

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

4. Наблюдател

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

В интерес на простотата помислете какво се случва, когато следвате някого в Twitter. По същество молите Twitter да ви изпрати (наблюдателя) актуализации на туит на човека (обекта), който сте последвали. Моделът се състои от двама участници, наблюдателя, който се интересува от актуализациите и обекта, който генерира актуализациите.

Субектът може да има много наблюдатели и е взаимоотношение един към много. Наблюдателят обаче е свободен да се абонира за актуализации и от други теми. Можете да се абонирате за новини от Facebook страница, която би била темата и винаги, когато страницата има нова публикация, абонатът ще вижда новата публикация.

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

5. Строител

Както подсказва името, за изграждане на обекти се използва модел на конструктор. Понякога обектите, които създаваме, могат да бъдат сложни, съставени от няколко под-обекти или да изискват сложен конструктивен процес. Упражнението за създаване на сложни типове може да се опрости с помощта на модела на строителя. Композитен или обобщен обект е това, което строителят обикновено изгражда.

Ключово съображение: Моделът на строителя може да изглежда подобен на модела на „абстрактната фабрика“, но една разлика е, че моделът на строителя създава обект стъпка по стъпка, докато абстрактният фабричен модел връща обекта в един ход.

6. Адаптер

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

Ако имате две приложения, като едното изплюва изход като XML, а другото изисква JSON вход, тогава ще ви трябва адаптер между двете, за да работят безпроблемно.

7. държава

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

Искате ли да продължите да учите?

Със схемите за дизайн на софтуер: Най-добри практики за разработчици ще имате шанс да направите повече от просто да прочетете теорията. Ще можете да се потопите дълбоко в реални проблеми и да разберете практически решения с примери за кодове от реалния живот.

Курсът е базиран на популярната книга от „Бандата на четиримата“, но представена в интерактивен, лесен за смилане формат. Ще овладеете интерактивно 23-те известни дизайнерски модела от книгата, ще научите правилните приложения на 3 ключови типа дизайнерски модели (творчески, структурни и поведенчески) и ще се научите да включвате тези дизайнерски модели в собствените си проекти.

Вижте го сега.

Първоначално публикувано на blog.educative.io на 7 ноември 2018 г.