Класс с одним методом - лучший подход?

Раньше мне нравились служебные классы, наполненные статическими методами. Они объединили вспомогательные методы, которые в противном случае стали бы причиной избыточности и адского обслуживания. Они очень просты в использовании, без создания экземпляров, без удаления, просто огонь и забыть. Думаю, это была моя первая невольная попытка создать сервис-ориентированную архитектуру - множество сервисов без сохранения состояния, которые просто выполняли свою работу, и ничего больше. Однако по мере роста системы появляются драконы.

Полиморфизм
Допустим, у нас есть метод UtilityClass.SomeMethod, который радостно гудит. Вдруг нам нужно немного изменить функционал. Большая часть функциональности осталась прежней, но, тем не менее, нам нужно изменить пару частей. Если бы это был не статический метод, мы могли бы создать производный класс и при необходимости изменить содержимое метода. Поскольку это статический метод, мы не можем. Конечно, если нам просто нужно добавить функциональность до или после старого метода, мы можем создать новый класс и вызвать внутри него старый, но это просто мерзко.

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

Тестирование
Это в основном идет рука об руку с проблемами интерфейса, упомянутыми выше. Поскольку наши возможности по замене реализаций очень ограничены, у нас также будут проблемы с заменой производственного кода тестовым кодом. Опять же, мы можем заключить их в оболочку, но это потребует от нас изменения больших частей нашего кода, чтобы иметь возможность принимать оболочки вместо фактических объектов.

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

Подъем параметров
Начнем с того, что этот маленький симпатичный и невинный статический метод может принимать один параметр. По мере роста функциональности добавляется пара новых параметров. Вскоре добавляются дополнительные параметры, которые являются необязательными, поэтому мы создаем перегрузки метода (или просто добавляем значения по умолчанию на языках, которые их поддерживают). Вскоре у нас есть метод, который принимает 10 параметров. Действительно обязательны только первые три, параметры 4-7 необязательны. Но если указан параметр 6, необходимо также заполнить 7-9 ... Если бы мы создали класс с единственной целью делать то, что делал этот статический метод, мы могли бы решить эту проблему, взяв необходимые параметры в конструктор и позволяет пользователю устанавливать необязательные значения через свойства или методы для одновременной установки нескольких взаимозависимых значений. Кроме того, если метод вырос до такого уровня сложности, он, скорее всего, в любом случае должен быть в своем собственном классе.

Требование от потребителей создать экземпляр класса без всякой причины
Один из наиболее распространенных аргументов - почему требовать, чтобы потребители нашего класса создавали экземпляр для вызова этого единственного метода, не имея при этом никакого смысла. для экземпляра потом? Создание экземпляра класса - очень дешевая операция для большинства языков, поэтому скорость не является проблемой. Добавление дополнительной строчки кода для потребителя - это невысокая цена, позволяющая заложить основу для гораздо более удобного в обслуживании решения в будущем. И, наконец, если вы хотите избежать создания экземпляров, просто создайте одноэлементную оболочку вашего класса, которая позволяет легко повторно использовать - хотя это требует, чтобы ваш класс не имел состояния. Если он не без состояния, вы все равно можете создавать статические методы-оболочки, которые обрабатывают все, но при этом дают вам все преимущества в долгосрочной перспективе. Наконец, вы также можете создать класс, который скрывает создание экземпляра, как если бы он был синглтоном: MyWrapper.Instance - это свойство, которое просто возвращает new MyClass ();

Только ситхи разбираются в абсолютных вещах
Конечно, есть исключения из моей неприязни к статическим методам. Истинные служебные классы, не представляющие риска раздувания, являются отличным случаем для статических методов - например, System.Convert. Если ваш проект разовый и не требует обслуживания в будущем, общая архитектура на самом деле не очень важна - статическая или нестатическая, на самом деле не имеет значения - однако скорость разработки имеет значение.

Стандарты, стандарты, стандарты!
Использование методов экземпляра не мешает вам также использовать статические методы, и наоборот. При условии, что дифференциация обоснована и стандартизирована. Нет ничего хуже, чем смотреть на бизнес-уровень, разросшийся по разным методам реализации.

Я предпочитаю статику. Поскольку класс не представляет объект, нет смысла создавать его экземпляр.

Классы, которые существуют только для своих методов, следует оставить статическими.

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

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

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

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

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

Я полагаю, что на основании предоставленной информации сложно ответить.

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

Конечно, трудно точно сказать, почему вам нужно создать один класс только для этого одного метода. Является ли это типичной ситуацией «класса коммунальных услуг», как предполагает большинство? Или вы реализуете какой-то класс правил, которых в будущем может быть больше.

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

Можно ли сделать ваш класс статическим?

Если да, то я бы сделал его классом «Утилиты», в который я бы поместил все свои классы с одной функцией.

Если этот метод не имеет состояния и вам не нужно передавать его, тогда имеет смысл определить его как статический. Если вам ДЕЙСТВИТЕЛЬНО нужно передать метод, вы можете рассмотреть возможность использования делегировать, а не один из других предложенных вами подходов.

Для простых приложений и internal помощников я бы использовал статический метод. Что касается приложений с компонентами, мне нравится Managed Extensibility Framework. Вот отрывок из документа, который я пишу, чтобы описать шаблоны, которые вы найдете в моих API.

• Services
  • Defined by an I[ServiceName]Service interface.
  • Экспортируется и импортируется по типу интерфейса.
  • Единственная реализация предоставляется хост-приложением и используется внутри и / или расширениями.
  • Методы в интерфейсе службы являются потокобезопасными.

В качестве надуманного примера:

public interface ISettingsService
{
    string ReadSetting(string name);

    void WriteSetting(string name, string value);
}

[Export]
public class ObjectRequiringSettings
{
    [Import]
    private ISettingsService SettingsService
    {
        get;
        set;
    }

    private void Foo()
    {
        if (SettingsService.ReadSetting("PerformFooAction") == bool.TrueString)
        {
            // whatever
        }
    }
}

Я бы просто все сделал в конструкторе. вот так:

new MyClass(arg1, arg2, arg3);// the constructor does everything.

or

MyClass my_object(arg1, arg2, arg3);

Еще один важный вопрос, который следует учитывать, - будет ли система работать в многопоточной среде, и будет ли потокобезопасным иметь статический метод или переменные ...

Обратите внимание на состояние системы.

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

Если у вас нет контроля над классом arg1, украсьте его:

class Arg1Decorator
    private final T1 arg1;
    public Arg1Decorator(T1 arg1) {
        this.arg1 = arg1;
    }
    public T myMethod(T2 arg2, T3 arg3) {
        ...
    }
 }

 arg1d = new Arg1Decorator(arg1)
 arg1d.myMethod(arg2, arg3)

Причина в том, что в ООП данные и методы, обрабатывающие эти данные, принадлежат друг другу. Кроме того, вы получаете все преимущества, о которых упоминал Марк.

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

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

public abstract class DoSomethingClass<T>
{
    protected abstract void doSomething(T arg1, T arg2, T arg3);
}

public abstract class ReturnSomethingClass<T, V>
{
    public T value;
    protected abstract void returnSomething(V arg1, V arg2, V arg3);
}

public class DoSomethingInt extends DoSomethingClass<Integer>
{
    public DoSomethingInt(int arg1, int arg2, int arg3)
    {
        doSomething(arg1, arg2, arg3);
    }

    @Override
    protected void doSomething(Integer arg1, Integer arg2, Integer arg3)
    {
        // ...
    }
}

public class ReturnSomethingString extends ReturnSomethingClass<String, Integer>
{
    public ReturnSomethingString(int arg1, int arg2, int arg3)
    {
        returnSomething(arg1, arg2, arg3);
    }

    @Override
    protected void returnSomething(Integer arg1, Integer arg2, Integer arg3)
    {
        String retValue;
        // ...
        value = retValue;
    }
}

public class MainClass
{
    static void main(String[] args)
    {
        int a = 3, b = 4, c = 5;

        Object dummy = new DoSomethingInt(a,b,c);  // doSomething was called, dummy is still around though
        String myReturn = (new ReturnSomethingString(a,b,c)).value; // returnSomething was called and immediately destroyed
    }
}