ТВЕРДЫЕ ПРИНЦИПЫ. Как не замять все на более высоком уровне класса?

Question

Я только что закончил Java-приложение, используя в основном классы Utility, а затем в выходные прочитал о принципах SOLID, поэтому я реорганизую все приложение, следуя этому принципу. Есть одна проблема, с которой я столкнулся при испытании, поэтому я должен делать это неправильно, поэтому кто-нибудь может привести меня на правильный путь? Пример:

public interface ID { }

public class D implements ID {
  //this class has a lot of dependencies that I do not want in class B but at some point
 // I have to create it. When is that point?
}

public interface IC { }

public class C implements IC {
  //this class has a lot of dependencies that I do not want in class B
}

public interface IB { }

public class B implements IB {
  public IC c;
  public ID d; 

  // this class depends on the 2 (or more) interfaces IC and ID so 
  // it won't have dependencies on concrete classes. But if the 
  // concrete classes are not used, then they all start bubbling up to the          
  // higher level class (let say class A below), and class A would know about and have 
  // dependencies on way so many objects, doesn't it?
}

public class A {
   ID d = new D();
   IC c = new C();
   IB b = new B(d, c); // b could given to some other classes
}

Как видите, чем больше абстрактный уровень и чем больше у меня объектов, тем хуже он становится. Какова ваша техника, чтобы уменьшить это?

Моей первой мыслью было иметь клиент для интерфейсов посередине, который знает все о конкретных классах этих интерфейсов (вроде как фабричный класс), затем класс А будет использовать этот класс клиента, но проблема все еще остается. Класс A зависит от класса Client, который зависит от других конкретных классов. Я просто делаю длинную цепь вместо множества коротких.

Answer 1

Этот дизайн выглядит хорошо для меня. Нет необходимости создавать дополнительные слои абстракции над классом A, поскольку, как вы правильно поняли, это никогда не закончится. Система должна иметь преимущество, абстракции должны быть разрешены в каком-то месте. Делать это в классе A - это нормально, если этот класс отвечает только за соединение других объектов (так что вы можете назвать класс A "Конфигурация").

Поэтому, если вы хотите работать только с простой Java без каких-либо фреймворков, вы можете использовать этот дизайн. Использование Spring (или любой другой библиотеки внедрения зависимостей) для DI может быть плюсом, но вводите его, только если вы считаете, что это необходимо. Между прочим, выполнение внедрения зависимостей с помощью JavaConfig в Spring приведет к тому же самому коду, что и текущий класс A, с некоторыми аннотациями.