Утилита класса статических методов и наследования

Question

В моем приложении есть служебный класс со статическими методами, которые отвечают за отображение уведомлений и, при необходимости, отправку электронных писем, когда происходит что-то плохое:

public static void sendEvent(final String description, final String name) {
    ....
    SmtpParms smtpParams = readSmtpParms();
    ....
}

private static SmtpParms readSmtpParms() {
    // read from properties file
    ....
}

Наша кодовая база совместно используется двумя приложениями.Приложение A считывает параметры SMTP из файла свойств.Я работаю в основном над Приложением B. Приложение B не использовало эту функцию электронной почты, но все еще совершало звонки, чтобы показывать уведомления о событиях в нашем графическом интерфейсе.Теперь приложение B должно прочитать параметры SMTP из базы данных.

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

Я думаю, что если я смогу выделить readSmtpParms в отдельный класс, это может помочь.Но я не могу придумать, как передать источник (файл свойств в сравнении с базой данных) экземпляру служебного класса без изменения сигнатуры метода sendEvent.Я полагаю, что альтернативой может быть создание другого метода sendEventUsingDatabase, но тогда мне все равно придется обновить все ссылки на sendEvent в коде приложения B.

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

Answer 1

Вы приводите два случая радикально различного поведения (.properties по сравнению с базой данных), что заставляет меня думать, что это не должны быть статические методы. Вам нужен интерфейс, чтобы приложения A и B могли подключаться по своему собственному поведению.

Answer 2

Метод статической утилиты не очень подходит для случая «отправки электронной почты».

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

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

Теперь выесть один класс, который вы можете использовать, и загрузка с config, полученным из db, и одна оболочка, соответствующая сигнатуре статического метода утилиты, используемой в устаревшем коде.

Answer 3

Как только в ваших классах появляются статические методы, тестирование становится сложным. Вы не сможете издеваться. Это еще одна причина для рефакторинга вашего кода и избавления от статических методов.

Answer 4

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

Старайтесь использовать как можно меньше.

Поэтому ответ таков: вам нужно перейти на другой подход.