Есть ли какая-то веская причина для нестатического метода?

Question

У меня есть эта функция SaveCheckedStateToDB():

public class oDaA_DBUtils { 

    // TOOD: Perhaps this should not be static, and I should force callers to instantiate the class first? 
    public static void SaveCheckedStateToDB(int AOptionSelected, String id, boolean AToggledOn) 
    { 
     // 
    } 
} 

... что я изменил «статический» после получения статического о вызове его здесь перед добавлением «статический» ключевое слово:

  cbOnDemand.setOnCheckedChangeListener(new OnCheckedChangeListener() 
      { 
      @Override 
       public void onCheckedChanged(CompoundButton buttonView, boolean isChecked) 
       { 
       // Contact id is a string? 
       oDaA_DBUtils.SaveCheckedStateToDB(oDaA_Consts.ALERT_ON_DEMAND, id, isChecked); 
       } 
      }); 

Теперь он компилируется, но является ли это «неправильным» способом работы? Должен ли я удалять «статические» приложения/украшения и принудительные вызовы для создания экземпляра класса до вызова SaveCheckedStateToDB()?

Answer 1

Нет причин для его нестатического включения. Этот метод не нуждается в каком-либо «состоянии» его класса, так как он, очевидно, является служебным классом, поэтому должен быть статическим.

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

private oDaA_DBUtils { 
    // no instances allowed! 
} 

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

public class OdaaDbUtils 
public static void saveCheckedStateToDb(....) 

Answer 2

вы можете использовать статические функции, где

1. вам не нужны, не статические члены класса или методы в этой функции.

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

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

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

Answer 3

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