Що таке диспетчер повідомлень?<\/em><\/p>\n\n\n\n Зараз опишу речі, які мають знати більшість програмістів. У принципі, у самій назві вже є відповідь на це питання. Це диспетчер, який розподіляє повідомлення<\/a>. Цей компонент побудований на патерні Посередник. Завдання цього посередника передати повідомлення<\/a> від відправника одержувачу. Як на словах, так і на схемі, все виглядає дуже просто.<\/p>\n\n\n\n Ну і виникає слушне питання, як це може спростити архітектуру? Все просто. При використанні диспетчера повідомлень класам не потрібно знати одне одного. Класам потрібно лише знати про самого диспетчера та про повідомлення<\/a>, з яким ці класи можуть працювати. Це дозволяє спростити взаємодію класів між собою і, як наслідок, спростити архітектуру програми. Спробую пояснити докладніше.<\/p>\n\n\n\n Жирний плюс диспетчер повідомлень.<\/em><\/p>\n\n\n\n Основний плюс диспетчера повідомлень у призначенні, тобто у тому навіщо його вигадали. Як писав раніше, основне його завдання прибрати залежності об’єктів один від одного. Використовуючи диспетчер повідомлень, нам не потрібні посилання на одержувача у відправнику. Все що повинні знати відправник та одержувач – це певний формат повідомлення<\/a>.<\/p>\n\n\n\n То що ми можемо поліпшити за допомогою диспетчера повідомлень? Найперше що спадає на думку – це події. Припустимо, у нас є така подія:<\/p>\n\n\n\n І ми на нього підписуємось.<\/p>\n\n\n\n І нам потрібно одразу написати ось це:<\/p>\n\n\n\n Як усі Ви, сподіваюся, знаєте, якщо не зробити відписку від події, то підписаний об’єкт не вийде з пам’яті. Наслідки також, підозрюю, розумієте. І якщо Ви думаєте, що це нісенітниця і не проблема, то скажу так. Я багато разів зустрічав ситуацію, коли забували робити відписку і більше того, підписку копіювали та забували виправляти плюс на мінус. Результат виходив веселий.<\/p>\n\n\n\n Тож чим тут може допомогти диспетчер повідомлень? Перше, класу B не потрібно знати про клас A. Отже, ми не прив’яжемо один до одного і якщо клас A стане не потрібен, то збирач сміття його видалить без проблем. Все, що нам потрібно – це домовитися про формат повідомлення<\/a>, яке клас A може надіслати, а клас B отримати та обробити.<\/p>\n\n\n\n І тут постає питання, як диспетчер повідомлень дізнається, що клас A надсилає повідомлення<\/a> класу B? Ну на те він і диспетчер, щоб знати. Описувати нутрощі диспетчера повідомлень тут не буду. Це тема окремої статті. Це тема окремої статті.<\/p>\n\n\n\n У класу A має бути посилання диспетчер повідомлень. А клас B повинен підписатися у диспетчері на потрібне йому повідомлення<\/a>. І коли клас A відправляє повідомлення<\/a> до диспетчера, то диспетчер переправляє це повідомлення<\/a> до класу B, який підписаний на це повідомлення<\/a>. І тут Ви можете сказати: Так, а в чому різниця? І там, і там потрібне посилання. І там, і там треба передплатити. І класи будуть залежні від диспетчера повідомлень. Начебто логічно, але є нюанс.<\/p>\n\n\n\n Якщо грамотно реалізувати диспетчер повідомлень, то збирач сміття може без проблем усунути підписаний клас, коли він буде вже не потрібен. Навіть якщо ми забудемо відписати клас. Наступне, класам потрібне лише одне посилання, це посилання диспетчер повідомлень. Класам знати одне про одного не потрібно.<\/p>\n\n\n\n Давайте порівняємо. Допустимо, у нас є три класи A, B, C. Класи B і C повинні реагувати на подію в класі A. А клас C реагувати на подію в класі B.<\/p>\n\n\n\n Як Ви бачите, як і раніше, щоб обробити події класу нам потрібне посилання на об’єкт цього класу. Думаєте не реально? Ось Вам простий приклад.<\/p>\n\n\n\n Програма руху автомобіля. Коли їде автомобіль, то відбуваються різні події: поворот ліворуч, натиснута педаль газу, включено п’яту швидкість, натиснуто гальмо тощо. Як думаєте скільки подій буде під час руху автомобіля? Очевидно більше двох десятків. І є клас, який реагує на всі ці події, обробляє та записує їх у базу. Виходить, він повинен підписатися на всі ці події. І як виглядатиме ця передплата?<\/p>\n\n\n\n Тепер подивимося на приклад із диспетчером повідомлень.<\/p>\n\n\n\n Краса? Все, що нам потрібно – це посилання на диспетчер повідомлень. Ми можемо підписуватися на сотні повідомлень від інших класів, не знаючи про них нічого.<\/p>\n\n\n\n Давайте розглянемо ще один приклад, де може бути корисним диспетчер повідомлень. Є клас A, у якому є клас B, який виконує обробку певних даних. І функціонал цієї обробки потрібно викликати у класі C. Як це буде виглядати у класичному варіанті. Нам потрібно буде або делегувати виклик методу обробки класу B із класу A, або повернути посилання на клас B. Візьмемо перший варіант.<\/p>\n\n\n\n Як бачите нам знову потрібні посилання на класи, що реалізує потрібний функціонал. Плюс додатковий код із делегування. А якщо ці класи у різних бібліотеках і вони не повинні знати одне про одного? Тоді нам доведеться створити інтерфейси. Іще додатковий код.<\/p>\n\n\n\n А як це виглядатиме з диспетчером повідомлень.<\/p>\n\n\n\n І знову краса. Класи не залежать один від одного. Вони взагалі не знають одне про одного.<\/p>\n\n\n\n І що ж ми маємо?<\/em><\/p>\n\n\n\n Я навів маленькі приклади якомога стандартні реалізації замінити патерном Посередник, який реалізує диспетчер повідомлень.<\/p>\n\n\n\n Як я спочатку писав, у нас в компанії на проекті<\/a> використовується диспетчер повідомлень. У проекті використовується плагінна система і є функціонал перестарту плагінів. Грубо кажучи, під час перестарту всі плагіни повинні видалятися і створюватися знову. І оскільки у нас класи плагінів не прив’язуються до інших класів подіями та сильними посиланнями, то вони видаляються збирачем сміття без проблем. Що не призводить до витоків пам’яті. Це було встановлено неодноразовими тестами. І ось цей момент дозволяє подальшу розробку та підтримку проекту без огляду на проблему втрати пам’яті.<\/p>\n\n\n\n Якщо брати саме наш диспетчер повідомлень, він дає додаткову гнучкість у обробці повідомлень. Наприклад, ми можемо обробляти повідомлення<\/a> по черзі асинхронно окремому потоці або синхронно в поточному потоці. Також можемо виставити пріоритети обробникам повідомлень, тобто вказати хто з обробників оброблятиме це повідомлення<\/a> першим, хто другим і т.д. Можемо після обробки повідомлення<\/a> перервати його подальшу обробку, щоб не витрачати час на виклики інших оброблювачів, зареєстрованих для обробки цього повідомлення<\/a>. Ще реалізовано можливість повернення результатів обробки повідомлення<\/a>.<\/p>\n\n\n\n Простіше кажучи, Ви можете собі створити диспетчер повідомлень з потрібним Вам функціоналом, який буде зручнішим і гнучкішим за звичайні події.<\/p>\n\n\n\n Що стосується мене особисто, то використання диспетчера повідомлень мені приносить своєрідне задоволення. З ним багато спрощується, зокрема трудовитрати.<\/p>\n\n\n\n![\"\"](\"https:\/\/blog.bithide.io\/wp-content\/uploads\/2023\/11\/ПДС_1.png\")
<\/figure>\n\n\n\npublic class A\n{\n public Action<object> OnDoIt;\n}\n<\/code><\/pre>\n\n\n\npublic class B\n{\n public void Init(A a)\n {\n a.OnDoIt += DoIt;\n }\n}\n<\/code><\/pre>\n\n\n\npublic class B\n{\n ...\n public void Deinit()\n {\n a.OnDoIt -= DoIt\n }\n}\n<\/code><\/pre>\n\n\n\npublic class A\n{\n public Action<object> EventInA;\n}\n\n\npublic class B\n{\n public Action<object> EventInB;\n\n public void Init(A a)\n {\n a.EventInA += ProcessA;\n }\n\n public void Deinit()\n {\n a.EventInA -= ProcessA;\n }\n\n private void ProcessA(object messageA)\n {\n ...\n }\n}\n\n\npublic class C\n{\n public void Init(A a, B b)\n {\n a.EventInA += ProcessA;\n b.EventInB += ProcessB;\n }\n\n public void Deinit()\n {\n a.EventInA -= ProcessA;\n b.EventInB -= ProcessB;\n }\n\n private void ProcessA(object messageA)\n {\n ...\n }\n\n private void ProcessB(object messageB)\n {\n ...\n }\n}\n<\/code><\/pre>\n\n\n\npublic class MessageDispatcher\n{\n}\n\n\npublic class A\n{\n public void Init(MessageDispatcher md)\n {\n }\n\n public void ProcessA()\n {\n md.SendMessage(messageA);\n }\n}\n\n\npublic class B : IMessageClient\n{\n public void Init(MessageDispatcher md)\n {\n md.Subscribe(MessageA, this);\n }\n\n public void ProcessMessage(IMessage msg)\n {\n \/\/ Обработка сообщений\n }\n\n public void ProcessB()\n {\n md.SendMessage(messageB);\n }\n}\n\n\npublic class C : IMessageClient\n{\n public void Init(MessageDispatcher md)\n {\n md.Subscribe(MessageA, this);\n md.Subscribe(MessageB, this);\n }\n\n public void ProcessMessage(IMessage msg)\n {\n \/\/ Обработка сообщений\n }\n}\n<\/code><\/pre>\n\n\n\npublic class A\n{\n private B b;\n\n public void Init()\n {\n b = new B();\n }\n\n public void ProcessB(MessageC messageC)\n {\n b.ProcessB(messageC)\n }\n}\n\n\npublic class B\n{\n public void ProcessB(MessageC)\n {\n \/\/ Обрабатываем данные\n }\n}\n\n\npublic class C\n{\n public void Init(A a)\n {\n }\n\n public void ProcessC()\n {\n a.ProcessB(messageC);\n }\n}\n<\/code><\/pre>\n\n\n\npublic class MessageDispatcher\n{\n}\n\n\npublic class A\n{\n private B b;\n\n public void Init()\n {\n b = new B();\n }\n}\n\n\npublic class B : IMessageClient\n{\n public void Init(MessageDispatcher md)\n {\n md.Subscribe(MessageC, this);\n }\n\n public void ProcessMessage(IMessage msg)\n {\n \/\/ Обработка сообщения\n }\n}\n\n\npublic class C\n{\n public void Init(MessageDispatcher md)\n {\n }\n\n public void ProcessC()\n {\n md.SendMessage(messageC);\n }\n}\n<\/code><\/pre>\n\n\n\n