Шаблон проектирования для двух разных «стратегий», которые не реализуют один и тот же интерфейс

Question

Я создал некоторую программу с ReactJS и SocketIO, которая служит полностью настраиваемым инструментом для связи с сервером socketIO.

Вы можете регистрировать события для прослушивания, отправлять сообщения любого типа, передавать объект конфигурации в соединение и т. Д.

Теперь я решил добавить поддержку собственных веб-сокетов.Проблема в том, что нативные веб-сокеты проще и не реализуют ту же функциональность, что и SocketIO.

Например, у меня есть этот метод в моем контейнере React (где сконцентрирована вся моя основная логика, без Redux):

registerEventToSocket = (instanceId, socket, eventName) => {
      socket.off(eventName);

      socket.on(eventName, (...args) => {           
        const lastArg = args[args.length - 1];
        const isFunction = this.isFunction(lastArg);

        if (isFunction) {
          lastArg();//If a callback was supplied from the server, it is invoked.
          var index = args.indexOf(lastArg);
          if (index > -1) {
            args.splice(index, 1);
          }

        }

        this.addMessageToState(instanceId, eventName, args, false)
      })
    }

Этот метод вызывается, когда пользователь добавляет событие" слушать.В случае нативных веб-сокетов есть только одно событие для прослушивания, которое является событием «onmessage», поэтому вся эта функциональность не имеет значения.

Приложение делает еще несколько вещей, которые были бы бесполезны с нативными сокетами,как вариант «прослушивать все входящие события».

Я пытаюсь придумать какой-нибудь хороший шаблон проектирования, который я мог бы использовать для создания здесь некоторого полиморфизма, чтобы иметь дело как с делом SocketIO, так и сродной.

Я знаком с "шаблоном стратегии", который я часто использовал, , но в моем случае обе "стратегии" реализуют два различных интерфейса , которые нарушают принципы SOLID.,

Есть предложения?

Answer 1

Это органическая эволюция типичной программы. Я думаю, что теперь ваша главная проблема - решить, какие функции будет поддерживать ваш базовый драйвер. В существующем состоянии клиент слишком связан с реализацией (SocketIO). Вам необходимо определить интерфейс для всех драйверов WebSocket и адаптировать к нему реализации.

Паттерн стратегии здесь не применим, это паттерн поведения. Это структурный вопрос. Вы можете использовать адаптер или мост в зависимости от ваших требований.