有一个类代表你的整个程序是不是很糟糕的设计？

Question

我没有使用单例，而是创建了一个类来保存每个组件的实例。我们叫它MainApp吧。MainApp在程序的入口点被初始化，并确定所有组件和资源的生存期。它有一个单一的责任，那就是一个组件的集合。这就是为什么首先它不觉得是个坏主意的原因。但是，有些组件需要访问其他组件，几乎所有其他组件都需要一个组件。为了解决这个问题，我使用了依赖注入，但这使得这些组件依赖于MainApp。感觉就像MainApp刚刚成为所有组件的一个大型中介类。

回到我的问题:这类课程设计不好吗？什么是更好的选择？或者这个类不一定是糟糕的设计，这个问题是否更多地与很多依赖它的事实有关？

Answer 1

这个MainApp类本身并不是一个坏主意，但可能会重新发明轮子。

通常，您需要一个“中心”组件来编排整个依赖注入的概念。另外，您最好使用现成的解决方案(例如，在Java容器中)。

但是，服务不应该依赖于MainApp，而应该依赖于它们所需要的其他服务。假设您有一个用户服务，它需要一个Repository服务。你的问题听起来就像你现在做的那样：

// BAD
class UserService {
    private MainApp mainApp;

    UserService(MainApp mainApp) {
        this.mainApp = mainApp;
    }

    void doSomethingThatNeedsARepository() {
        this.mainApp.getRepositoryService().doStuff();
    }
}

// in MainApp
UserService userService = new UserService(this);

如果您这样做，您将失去对哪个服务需要哪个其他服务的控制，从而造成很大的混乱。

只需注射你真正需要的：

// Better
class UserService {
    private RepositoryService repository;

    UserService(RepositoryService repository) {
        this.repository = repository;
    }

    void doSomethingThatNeedsARepository() {
        this.repository.doStuff();
    }
}

// in MainApp
RepositoryService repository = new RepositoryService(...);
UserService userService = new UserService(repository);

(我们可以继续讨论使用接口而不是具体服务的优点，但其他人可能会这么做；-)

Answer 2

但是，有些组件需要访问其他组件，几乎所有其他组件都需要一个组件。为了解决这个问题，我使用了依赖注入，但这使得这些组件依赖于MainApp。感觉就像MainApp刚刚成为所有组件的一个大型中介类。

使用MainApp作为依赖注入的组合根并不会使其他任何东西依赖于它，除非您正在做一些愚蠢的事情，比如让其他组件知道MainApp的存在。

MainApp的S的工作是构造和注入组件。这不是组件应该谈论或问问题的东西。坚持这一点，你的设计就好了。

这样做并不能使MainApp“代表”您的整个程序。这就是构建它的持久对象图的简单方法。一旦这样做了，MainApp就可以调用某个组件上的start()，然后让开，再也不会有人听到它了。

Answer 3

MainApp很好。它是一个构图的根。它应该充当粘合剂，注入依赖，连接生产者和侦听器，诸如此类的东西。

关于依赖注入，避免注入MainApp本身(除非平台的某些限制迫使您这样做)。相反，您可以让MainApp注入其他东西，包括工厂。如果您需要创建新类型来注入它们，那么很好，就这样做吧。

其他任何东西都不应该了解MainApp。MainApp的更改不应意味着组件的更改。