Как архитектурно лучше решить такую задачу (с точки зрения ооп)?

Question

[topuserman]

В фреймворке котором работают, есть некоторый встроенный класс - EventManager.
Который умеет добавлять, регистрировать обработчики событий и т.д.

Я бы хотел упростить сигнатуру одного из методов (чтобы входные параметры имели совсем иной формат).

Например:

был метод AttachEventHandler(module, type, handler) а я сделал такай метод:

SimpleAttachEventHandler(config) {
     // тут делаю еще какие-то дела
    AttachEventHandler(config.module, config.type, config.handler);  // т.е. внутри своего метода я дергаю тот же метод фреймворка
}

Расширять наследованием - не хотелось бы.
Подскажите пожалуйста, какие есть архитектурные решения?

Comments

[Vitsliputsli]

Подскажите пожалуйста, какие есть архитектурные решения?

Решения чего? Задачи ведь нет. Есть уже написанное решение неизвестной задачи.
К примеру, если нужно состыковать 2 объекта использующие разные интерфейсы, то можно воспользоваться паттерном адаптер. Быть может у вас такая задача, а может и нет.

Answer 1

[Денис Дерепко]

https://refactoring.guru/ru/design-patterns/decora...

Comments

[topuserman]

Декораток скорее-всего не то, т.к. он всего-лишь добавляет новые возможности в существующие методы.

А мне нужно кроме добавления нового функционала к одному методу, еще и его новый метод создать.

[Василий Банников]

topuserman, тогда адаптер.
Просто введи свой класс, который будет инкапсулировать оригинальный и давать наружу метод с другой сигнатурой.

[topuserman]

Василий Банников, в целом, я такой пример и привел, только разве это адаптер ?
Вроде суть адаптера в том, чтобы подгонять один класс, под другой. Т.е. адптер - это третий класс, который связывает два других.

[Василий Банников]

topuserman, Нет. Адаптер - это как раз класс, который адаптирует один интерфейс к другому. (емнип)
Тоесть у тебя есть интерфейс А и интерфейс Б, а адаптер зависит от интерфейса А и реализует интерфейс Б.

[topuserman]

Василий Банников, согласен, неправильно выразился по декоратору, не упомянув про интерфейсы.

Но если в нашем случае, есть интерфейса (потребителя, которому нужен какой-то особый интерфейс, под который мы хотим изменить).

Просто, есть необходимость сделать простую обертку над одним методом класса. Мне кажется адаптер не совсем подходит для такой задачи.

Если бы у меня был клиентский код, которому нужен был интерфейс А, а у меня интерфейс Б, то тогда нужен был бы адаптер для интерфейса А, который зависел бы от Б.

[topuserman]

возможно, ошибаюсь, и как раз через Адаптер и решается моя проблема..))

[Василий Банников]

topuserman, адаптер и без интерфейсов остаётся адаптером) Смысл просто в том что он логику работы не меняет, просто как-то изменяет внешний вид.
Если бы он прям что-то сложное инкапсулировал, то это был бы фасад.