Замяна на преките зависимости със съобщения
Понякога един модул просто трябва да уведоми другите, че в него са настъпor няHowви събития/промени и няма meaning Howво ще се случи с тази информация по-късно.
В този случай модулите изобщо не трябва да „знаят един за друг“, тоест да съдържат директни връзки и да си взаимодействат директно, а е достатъчно просто да обменят съобщения (съобщения) or събития (събития).
Понякога изглежда, че модулната комуникация чрез съобщения е много по-слаба от пряката зависимост. Всъщност, тъй като методите не се извикват, няма информация за класовете. Но това не е нищо повече от илюзия.
Вместо имената на методите, логиката започва да се обвързва с типовете съобщения, техните параметри и предаваните данни. Свързването на такива модули е размазано.
Преди беше така: извикваме методи - има свързаност, не извикваме методи - няма свързаност. Сега си представете, че модул А започва да изпраща малко по-различни данни в своите съобщения. И в същото време всички модули, зависими от тези съобщения, няма да работят правилно.
Да предположим, че по-рано, при добавяне на нов потребител, модулът за оторизация изпрати съобщението USER_ADDED и след актуализацията започна да изпраща това съобщение, когато се опитва да се регистрира и допълнително да посочи успешна регистрация or не в параметрите.
Ето защо е много важно механизмът за съобщения да се внедри много компетентно. Има различни шаблони за това.
Наблюдател. Използва се в случай на зависимост един към много, когато много модули зависят от състоянието на един - главният. Той използва механизма за изпращане по пощата, което означава, че основният модул просто изпраща едни и същи съобщения до всичките си абонати, а модулите, които се интересуват от тази информация, прилагат интерфейса „абонат“ и се абонират за списъка с имейли.
Този подход се използва широко в системи с потребителски интерфейс, позволявайки на ядрото на приложението (модела) да остане независимо, докато информира свързаните с него интерфейси, че нещо се е променило и трябва да се актуализира.
Тук форматът на съобщението е стандартизиран на ниво операционна система, чиито разработчици трябва да се погрижат за обратна съвместимост и добра documentация.
Организацията на взаимодействие чрез разпространение на съобщения има допълнителен „бонус“ - незадължителното съществуване на „абонати“ на „публикувани“ (т.е. изпратени) съобщения. Една добре проектирана система като тази позволява добавяне/премахване на модули по всяко време.
Автобус за съобщения
Можете да организирате обмена на съобщения и да използвате модела Mediator за това по различен начин .
Използва се, когато има зависимост между модулите много към много. Медиаторът действа като посредник в комуникацията между модулите, като действа като комуникационен център и елиминира необходимостта модулите изрично да се отнасят един към друг.
В резултат на това взаимодействието на модулите един с друг („всички с всички“) се заменя с взаимодействието на модулите само с посредник („един с всички“). Твърди се, че медиаторът капсулира взаимодействието между множество модули.
Това е така нареченият интелигентен посредник . Именно там разработчиците най-често започват да добавят своите патерици, които влияят върху поведението на отделните модули, като включват / изключват получаването на определени съобщения.
Типичен пример от реалния живот е контролът на трафика на летището. Всички съобщения от самолетите отиват до контролната кула на контролера, instead of да се изпращат директно между самолетите. И контролерът вече взема решения за това кои самолети могат да излитат or кацат и на свой ред изпраща съобщения до самолетите.
важно! Модулите могат да си изпращат не само прости съобщения, но и командни обекти. Такова взаимодействие е описано от шаблона Command. Долната линия е да капсулирате заявка за извършване на конкретно действие като отделен обект.
Всъщност този обект съдържа един единствен метод execute() , който след това ви позволява да предадете това действие на други модули за изпълнение като параметър и като цяло да извършвате всяHowви операции с командния обект, които могат да се извършват върху обикновени обекти.
Закон на Деметра
Законът на Деметра забранява използването на неявни зависимости: „Обект А не трябва да има директен достъп до обект С, ако обект А има достъп до обект Б и обект Б има достъп до обект С.“
Това означава, че всички зависимости в codeа трябва да са „изрични“ – класовете/модулите могат да използват само „своите зависимости“ в работата си и не трябва да преминават през тях към други. Добър пример е тристепенната архитектура. Интерфейсният слой трябва да работи с логическия слой, но не трябва да взаимодейства директно със слоя база данни.
Накратко, този принцип също е формулиран по следния начин: „Взаимодействайте само с непосредствени приятели, а не с приятели на приятели“. Така се постига по-малка кохерентност на codeа, Howто и по-голяма видимост и прозрачност на неговия дизайн.
Законът на Деметра прилага вече споменатия „принцип на минимално знание“, който е в основата на хлабавото свързване и се състои в това, че един обект / модул трябва да знае възможно най-малко подробности за структурата и свойствата на други обекти / модули и всичко като цяло, включително неговите собствени компоненти .
Една аналогия от живота: ако искате кучето да бяга, глупаво е да командвате лапите му, по-добре е да дадете командата на кучето и тя сама ще се справи с лапите си.
Композиция instead of наследство
Това е много голяма и интересна тема и заслужава поне отделна лекция. Много копия бяха счупени по тази тема в Интернет, докато не се постигне консенсус - използваме наследяване до минимум, композиция - до максимум.
Въпросът е, че наследяването всъщност осигурява най-силната връзка между класовете, така че трябва да се избягва. Тази тема е добре разгледана в статията на Herb Sutter „ Предпочитайте композицията пред наследяването “.
Когато започнете да изучавате модели на проектиране, ще срещнете цял куп модели, които управляват създаването на обект or неговата вътрешна структура. Между другото, мога да посъветвам в този контекст да обърнете внимание на модела Delegate / Delegate и модела Component , които идват от игрите .
Ще говорим повече за моделите малко по-късно.