Разликата в дизайна и архитектурния модел в софтуерното инженерство.

Това е стръмна крива на обучение. Преди да прочетете тази статия, ако не знаете за моделите на проектиране или архитектурните модели (в софтуерното инженерство), предлагам ви да потърсите някои основни препратки предварително в Интернет, като например Wikipedia.

TL DR;

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

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

Объркването

Много програмисти в днешно време все още са объркани относно разликата между моделите на проектиране и моделите на архитектурата или дори не знаят много за това. Както преди няколко часа, преди да реша да напиша тази публикация, моят приятел, който обсъждаше с мен относно известния MVC (Model View Controller), според него е модел на проектиране. Опитах се да му обясня възможно най-ясно и да го насоча към някакъв сайт, който обяснява, че MVC е по-скоро архитектурен модел. След това той ми отговори с връзка от GeeksforGeeks, която гласи, че MVC е шаблон за проектиране.

В първия параграф статията на GeeksforGeeks казва това

Моделът за дизайн на Model View Controller (MVC) указва, че приложението се състои от модел на данни, информация за представяне и информация за контрол. Моделът изисква всеки от тях да бъде разделен на различни обекти.

Но във втория параграф,

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

По-късно попитах приятеля си,
„знаехте ли разликите между тях, дизайна и архитектурния модел?“,
„Разбира се, че не, моля обяснете към мен”

Ах, мамка му, ето го отново...

Моделът на дизайна

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

Моделите на проектиране са дестилирана общност, която можете да намерите в програмите. Позволява ни да деконструираме голяма сложна структура и да изградим с помощта на прости части. Той предоставя общо решение за клас проблеми — pyfunc

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

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

Има 3 класификации на дизайнерски модели.

  1. Модели за създаване
    за осигуряване на механизми за създаване на обекти, които увеличават гъвкавостта и повторното използване на съществуващ код. Типове: Абстрактна фабрика, конструктор, фабричен метод, набор от обекти, прототип, единичен елемент.
  2. Структурни модели
    за да обясните как да сглобявате обекти и класове в по-големи структури, като същевременно поддържате структурите гъвкави и ефективни. Типове: Адаптер, Bridge, Composite, Decorator, Facade, Flyweight, Private Class Data, Proxy.
  3. Поведенчески модели
    за грижа за ефективната комуникация и разпределяне на отговорностите между обектите. Типове: Верига от отговорност, Команда, Интерпретатор, Итератор, Медиатор, Спомен, Нулев обект, Наблюдател, Състояние, Стратегия, Метод на шаблона, Посетител.

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

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

„Добре, разбрах теорията. Но защо тези сложни дизайнерски модели изобщо са съществували?. Какъв е смисълът на всичко това? И трябва ли да науча това?“

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

  • Шаблоните за проектиране са набор от изпитани и тествани решения за често срещани проблеми при проектирането на софтуер. Дори никога да не се сблъсквате с тези проблеми, познаването на моделите все още е полезно, защото ви учи как да решавате всякакви проблеми, като използвате принципите на обектно-ориентирания дизайн.
  • Шаблоните за проектиране дефинират общ език, който вие и вашите съотборници можете да използвате, за да общувате по-ефективно. Можете да кажете, „О, просто използвайте Singleton за това.“ и всеки ще разбере идеята зад вашето предложение. Няма нужда да обяснявате какво е сингълтън, ако знаете модела и името му.

Шаблоните за проектиране казват как да пишете код ефективно, лесен за поддръжка, висока възможност за повторна употреба и разбира се четлив поради абстракцията — vrluckyin

„О, разбирам..., но можете ли да ми дадете някакъв пример?“
Ще ви дам основен пример с един от любимите ми модели,

Моделът на наблюдателя

Наблюдателят е един от дизайнерските модели в поведенческата класификация. За опростяване, този модел има 2 основни компонента, наблюдатели наблюдаем. Наблюдателят е обект, който наблюдава наблюдаем, докато наблюдаемият е отговорен за изпращане на информация (уведомяване) на наблюдателя.

Действието, което наблюдателят прави, за да се свърже с наблюдаемото, се нарича абонамент. И само observable може да изпраща информация до наблюдател, който вече е абониран за него.

Това е тип връзка едно към много. Защо? защото една наблюдаема може да има много наблюдатели и да изпраща информация (уведомяване) към тях.

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

Ще ви трябва WeatherObservable, за да извличате данни от сървър в някои от интервалите от време и да съобщавате данните на WeatherObserver, който вече е абониран.

Приказките са евтини, покажи ми кода

Разгледайте примера по-долу, написал съм го на езика Kotlin.

На първо място, ние декларираме интерфейса за наблюдаем и наблюдател. BaseObservableе реализиран с 2 функции, абониранеза наблюдателя, за да се абонира, и актуализацияза излъчване на промяна на данните към наблюдателя. Докато BaseObserverима само 1 функция за уведомяванеза получаване на данни (известие) от наблюдаеми.

След това създаваме наблюдаемия обект, който имплементира интерфейса BaseObservable. Ние също така декларираме списък с масиви, за да запазим наблюдателя, който вече е абониран.

Накрая обявяваме наблюдателя.

Този код е готов и когато функцията:

WeatherObservable.refresh()

се извиква някъде в кода, нашият наблюдаем ще излъчи промяната на данните от сървъра към всички наблюдатели, които вече са абонирани. Просто нали?

Стига за дизайн, нека започнем с архитектурата.

Моделът на архитектурата

Моделът на архитектурата е като абстрактно обяснение за това как структурирате вашето приложение. Според Уикипедия,

Архитектурният модел е общо решение за многократна употреба на често срещан проблем в софтуерната архитектура в даден контекст. Архитектурните модели са подобни на моделите за проектиране на софтуер, но имат по-широк обхват.

Това са шаблони за цялостното оформление на вашето приложение или приложения. Всички те имат предимства и недостатъци.

Съществуват много архитектурни модели, можете да видите списъка в Wikipedia. Но ще спомена 10-те често срещани архитектури:

  1. Слоеста шарка
  2. Модел клиент-сървър
  3. Модел главен-подчинен
  4. Модел на тръбен филтър
  5. Модел на брокер
  6. Модел равноправен
  7. Модел на автобус за събития
  8. Модел-изглед-контролер модел
  9. Модел на черна дъска
  10. Модел на преводач

Тези модели вече са обяснени подробно тук:



Накратко 10 често срещани софтуерни архитектурни модела
Чудили ли сте се някога как са проектирани системи от мащаб на големи предприятия? Преди да започне основната разработка на софтуер, ние трябва да…towardsdatascience.com



Дизайн срещу архитектура

Като цяло (изключете вътрешния си програмист за известно време) и архитектурата, и дизайнът обясняват „идеята“, но Архитектурата се фокусира върху абстрактния изглед на идеята, докато Дизайн се фокусира върху изгледа за изпълнение на идеята. Дизайнът е много по-детайлен от архитектурата.

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

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

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

Оттук се надявам да видите разликата между дизайна и архитектурните модели.

Препратки

Специални благодарности на Panditya, този, който ме запозна с основите на тези неща, и на Dhevanза дебата относно модела.

Искате ли да обясня всеки един модел на дизайн или да обясня повече подробности за тази тема в следващата публикация? моля, оставете коментар по-долу :)

Всяка критика или предложение са добре дошли.