Коротко и по делу — проблема: глобальный синглтон через Global.getInstance() скрывает зависимости, мешает тестированию и нарушает DIP/SRP. Рефакторинг — сделать зависимости явными и заменить прямые вызовы синглтона на инъекцию зависимостей (Constructor Injection / Interface), при необходимости использовать Factory или Service Locator как этап миграции.

Что применить и почему

В первую очередь — Dependency Injection (Constructor Injection): делает зависимости явными, упрощает мокирование и тесты; соответствует DIP (зависи от интерфейса) и SRP (классы не управляют созданием зависимостей).Интерфейс-абстракция для логики синглтона (например, GlobalService) — чтобы код зависел от абстракции, не от реализации.Factory / Provider — когда объект сложен в создании или нужна отложенная/условная инициализация.Service Locator — можно использовать как переходный вариант (мигрировать меньше кода), но он продолжает скрывать зависимости и ухудшает тестируемость в сравнении с DI.DI-контейнер (Spring, Guice) — уменьшает «богорутины» по биндингу, но добавляет зависимость от фреймворка.

Преимущества выбранного решения (DI + интерфейс)

Явные зависимости → проще читать код.Легко мокировать/подменять зависимости в тестах.Соответствие DIP и SRP.Локализация создаваемых объектов (т.е. легче управлять временем жизни).

Недостатки и компромиссы

Небольшой рефакторинг/шаблонный код (конструкторы, фабрики).Если используется ручной DI — возможно больше шаблонного кода; DI-фреймворки решают это, но добавляют зависимость.Service Locator сохраняет привычный стиль вызова, но не решает проблему скрытых зависимостей.

Пример рефакторинга в Java

Исходный фрагмент (плохо — прямой доступ к синглтону):

public class Global {
private static final Global INSTANCE = new Global();
public static Global getInstance() { return INSTANCE; }
public void doSomething() { /*...*/ }
}
public class Worker {
public void work() {
Global.getInstance().doSomething();
}
}

Шаги рефакторинга:
1) Ввести интерфейс:

public interface GlobalService {
void doSomething();
}

2) Сделать реализацию, адаптирующую текущий синглтон (или заменить синглтон на бин/компонент):

public class GlobalServiceImpl implements GlobalService {
// можно оставить внутренний синглтон или сделать обычным объектом, управляемым контейнером
@Override
public void doSomething() { Global.getInstance().doSomething(); }
}

3) Внедрить зависимость через конструктор (Constructor Injection):

public class Worker {
private final GlobalService globalService;
public Worker(GlobalService globalService) {
this.globalService = globalService;
}
public void work() {
globalService.doSomething();
}
}

4a) Создание в проде (ручной DI или контейнер):

GlobalService service = new GlobalServiceImpl();
Worker worker = new Worker(service);
worker.work();

4b) Пример теста с моками (JUnit + Mockito):

@ExtendWith(MockitoExtension.class)
public class WorkerTest {
@Mock
GlobalService mockService;
@Test
public void testWork_callsDoSomething() {
Worker worker = new Worker(mockService);
worker.work();
verify(mockService).doSomething();
}
}

Альтернатива — Factory/Provider (когда нужен ленивый/контекстный доступ):

public interface GlobalServiceProvider {
GlobalService get();
}
public class Worker {
private final GlobalServiceProvider provider;
public Worker(GlobalServiceProvider provider) { this.provider = provider; }
public void work() { provider.get().doSomething(); }
}

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

Service Locator (переходный вариант):

public class ServiceLocator {
private static final Map<Class<?>, Object> services = new ConcurrentHashMap<>();
public static <T> void register(Class<T> iface, T impl) { services.put(iface, impl); }
public static <T> T get(Class<T> iface) { return iface.cast(services.get(iface)); }
}
// использование
Worker worker = new Worker(ServiceLocator.get(GlobalService.class));

Минус: зависимости всё ещё скрыты в кодовой базе (класс зовёт локатор), но это упрощает миграцию.

Короткие рекомендации по переходу

Начните с интерфейса для глобального функционала.Внедряйте зависимость через конструктор во все потребители.Там, где много классов и тяжело рефакторить сразу, используйте Service Locator как временный адаптер, но планируйте перевести на DI.Используйте DI-контейнер для управления временем жизни и связями, если проект большой.

Резюме: правильный путь — заменить прямые вызовы Global.getInstance() на зависимости через интерфейсы и constructor injection; при необходимости применять Factory/Provider для создания и Service Locator только как временный шаг. Это улучшит тестируемость и соблюдение DIP/SRP; ценой будет небольшой рефакторинг и/или внедрение DI-инфраструктуры.