Чи клас утиліти повинен бути статичним? [зачинено]

Якщо мені доводиться розробляти клас Utility (наприклад, ByteUtils або StreamUtils або StringUtils), який найкращий вибір дизайну для них.

• Чи повинні вони бути статичними класами (оскільки у мене не буде збережених станів)
• Чи повинні вони бути нестатичними класами (так що, якщо об'єкти не використовуються, вони будуть gc'd)

PS: Під статичним класом я мав на увазі клас зі статичними методами (а не внутрішній статичний клас)

Будь ласка, дайте пораду щодо вибору дизайну для цього?

Якщо це утиліта загального призначення, статичний - це IMO краще. Ви заявили, що у вас не буде жодного стану для зберігання, тому я не розумію, чому ви повинні робити це нестатичним. Оголошення як статичне заощадить пам’ять.

Мої корисні класи виглядають так:

// final, because it's not supposed to be subclassed
public final class FooUtil {

    // private constructor to avoid unnecessary instantiation of the class
    private FooUtil() {
    }

    public static int doSomethingUseful() {
    }

    // ...
}

Зауважте, що, хоча це робить методи утиліти легко перевіряемыми і легкодоступними ззовні, це також ускладнює класи, які їх використовують, для модульного тестування, оскільки непросто знущатись над цими утилітарними методами. Наявність занадто багатьох таких класів корисних програм може бути ознакою відсутності дизайну ОО (процедурне програмування), і справді може зробити код важким для перевірки.

Якщо ви використовуєте фреймворк ін'єкцій залежностей (Spring, Guice, що завгодно), може бути непоганою ідеєю просто зробити клас утиліти інстанційним, використовуючи нестатичні методи, і зробити його ін'єкційним одиночним. Таким чином, класи, що використовують ці утилітні методи, можна перевірити, знущаючись над об’єктом утиліти.

Те, що щось може бути статичним, не означає, що воно має бути статичним.

До всього цього є ще одна думка: знущання. Складніше знущатися зі статичних методів у своїх тестах, ніж знущатися над поведінкою екземпляра класу.

Розмова про непотрібне розподілення купи та обробку об'єктів мені здається передчасною оптимізацією. JVM зробить досить гарну роботу, оптимізуючи подібний випуск.

Найпростіший спосіб визначити клас Utility - це перелік без екземплярів

public enum Utility {;
     public static int utilityMethod(int x) { /* ... */ }
}

Клас корисності не повинен мати жодного стану або мати мінімальний стан, тому вам не слід турбуватися про GC.

Ви можете мати інші класи з визначеним статусом, такі як Builder, Factory, ви можете створити об’єкт за бажанням і відкинути його, коли закінчите.

Добре зробити клас нестатичним за допомогою приватного конструктора:

• якщо ми зробимо клас статичним, тоді клас буде завантажений при розгортанні програми, якщо він нестатичний, то клас буде завантажений, коли буде викликаний один із його статичних методів
• створення приватного конструктора дозволить уникнути створення примірника класу

Зазвичай утилітні класи містять статичні методи і відсутні атрибути, цей підхід полегшує використання їх методів без створення екземпляра класу. Сподіваюся, це допомагає.

Якщо ви можете зробити їх статичними, тоді однозначно зробіть це!

Іншими словами, якщо вони не мають стану, вони повинні бути статичними.

Ну, якщо у вас немає стану для зберігання, тоді GC нічого не потрібно, тому я б пішов зі статичним, таким чином ви уникаєте зайвих розподілів купи та GC.

Класи чистої корисності зазвичай мають бути статичними. Коли у вас є клас з чітко визначеними вхідними та вихідними даними, без побічних ефектів і без стану, тоді за визначенням це повинен бути статичний клас.

Загалом, не додайте складності (в даному випадку введення залежності) до того, як це буде потрібно, і це має вигоду.

Тут ніхто не згадує, що статичні методи корисності не розширювані. Ви не можете замінити їх. Ви не можете скористатися перевагами ООП (зокрема, поліморфізмом, який є найпотужнішою функцією ООП). Це призводить до дублювання коду.

PS Я знайшов цю статтю дуже корисною. http://www.yegor256.com/2014/05/05/oop-alternative-to-utility-classes.html