Правилно софтуерно разлагане

Йерархична декомпозиция

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

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

Преди да изберете обекти, разделете системата на основни семантични блокове, поне психически. В малки applications това обикновено е много лесно да се направи: няколко нива на йерархия са напълно достатъчни, тъй като системата първо е разделена на подсистеми / пакети, а пакетите са разделени на класове.

Тази идея не е толкова тривиална, колкото изглежда. Например, Howва е същността на такъв общ „архитектурен модел“ като Model-View-Controller (MVC)?

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

Тогава се оказва, че модулите трябва по няHowъв начин да си взаимодействат, за това добавят контролер, чиято задача е да управлява взаимодействието на модулите. Също така в мобилната (класическа) version на MVC моделът Observer е добавен към него, така че View да може да получава събития от модела и да променя показаните данни в реално време.

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

• Бизнес логика;
• Потребителски интерфейс;
• База данни;
• Система за съобщения;
• Контейнер за обекти.

Първото разделяне обикновено разделя цялото приложение на 2-7 (максимум 10 части). Ако го разделим на повече части, тогава ще има желание да ги групираме и отново ще получим 2-7 модула от най-високо ниво.

Функционално разграждане

Разделянето на модули/подсистеми е най-добре на базата на задачите, които системата решава . Основната задача е разделена на съставните й подзадачи, които могат да се решават/изпълняват автономно, независимо една от друга.

Всеки модул трябва да отговаря за решаването на няHowва подзадача и да изпълнява съответната функция . В допълнение към функционалното преднаmeaning, модулът се характеризира и с набор от данни, необходими за изпълнението на функцията му, а именно:

Модул = Функция + Данни, необходими за нейното изпълнение.

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

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

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

Силна и слаба свързаност

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

Основният критерий за качеството на декомпозицията е доколко модулите са фокусирани върху решаването на задачите си и са независими.

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

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

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

Следствие от High Cohesion е Принципът на единната отговорност - първият от петте принципа на SOLID , според който всеки обект/модул трябва да има само една отговорност и не трябва да има повече от една причина за промяната му.

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

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

При правилен дизайн, ако промените един модул, няма да се налага да редактирате други or тези промени ще бъдат минимални. Колкото по-хлабава е връзката, толкова по-лесно е да напишете/разберете/разширите/поправите програмата.

Смята се, че добре проектираните модули трябва да имат следните свойства:

• Функционална цялост и пълнота - всеки модул изпълнява една функция, но я изпълнява добре и напълно, модулът самостоятелно изпълнява пълен набор от операции за изпълнение на своята функция.
• Един вход и един изход - на входа програмният модул получава определен набор от първоначални данни, извършва смислена обработка и връща един набор от резултатни данни, т.е. прилага се стандартният IPO принцип - вход -\u003e процес -\u003e изход.
• Логическа независимост - резултатът от работата на програмния модул зависи само от първоначалните данни, но не зависи от работата на други модули.
• Слаби информационни връзки с други модули - обменът на информация между модулите трябва да бъде сведен до минимум, ако е възможно.

Много е трудно за начинаещ да разбере How да намали още повече свързаността на модулите. Отчасти това знание идва с опит, отчасти - след четене на умни книги. Но най-добре е да анализирате архитектурите на съществуващите applications.

Композиция instead of наследство

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

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

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

При декомпозиране на система е желателно да проверите нейното качество, като си зададете въпросите: „Каква задача изпълнява всеки модул?“, „Колко лесни са модулите за тестване?“, „Възможно ли е да използвате модулите самостоятелно or в друга среда?" да повлияят на другите?"

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

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

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