Shared singleton instance

Question

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

Один экземпляр служебного класса создается в главном потоке и передается всем экземплярам других объектов:

SomeUtil util = new SomeUtil();

...

Foo foo = new Foo(util, arg1, arg2)
Bar bar = new Bar(util, arg3, arg4, arg5) 

Есть ли более элегантный способ достижения этого (т. Е. Шаблон проектирования)?

Answer 1

Как уже упоминалось, синглтон может быть альтернативой.Тем не менее, обратите внимание, что ваш текущий дизайн легко модульный тест (так как вы вводите зависимость SomeUtil, которая, таким образом, может быть легко заменена фиктивным объектом во время модульных тестов), в то время как Singleton делает модульное тестирование неудобным и трудным:

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

При этом, если это реальный служебный класс, т. е. он не имеет внутреннего состояния и не зависит от чего-либо, что может затруднить модульное тестирование (например, БД или файловая система), можно использовать его как Singleton (хотя напрашивается вопрос, зачем вам вообще его создавать - как правило, утилита классовТолько статические методы и закрытый конструктор для предотвращения создания экземпляров).

Answer 2

Почему вы передаете вокруг служебный объект?SomeUtil может иметь статические методы, так что методы в Foo и bar могут использовать его.

Кроме того, вы можете реализовать фактический шаблон синглтона.

Answer 3

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

public class SomeUtil {
    private static final SomeUtil instance = new SomeUtil();
    public static SomeUtil getInstance() { 
        return instance;
    }
    //...
}

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

Answer 4

Вероятно, самый хороший способ обойти это - добавить / использовать некоторую платформу Dependency Injection.

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

Answer 5

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