Question

我正在创建一个小的PHP 命令行应用程序，以便学习一些常见的设计模式和oop技术。

我已经设置了所有相关的类，以便它们不在内部实例化对象，而是通过构造函数为它们提供所需的对象。

现在的问题是我如何编排所有内容，以便每个对象获得它所需的依赖项。我已经阅读了有关依赖注入容器和框架的信息，但这对于一个小命令行应用来说似乎有点过分了+我很难理解它们如何适合我的应用程序。

目前流程如下：

在灵活性和简单性之间取得平衡的最佳方法是什么，因为我不相信设计（工厂周围）非常正确。

Answer 1

从它的声音来看，你的应用程序组织得相当好，构造与应用程序逻辑分开，你的依赖关系得到了清晰的管理。

您当然可以添加可配置的依赖项或使用依赖项注入框架，但是，除非应用程序需要，否则我建议避免这两种情况。如果您确实开始使用DI框架，请确保即使您正在使用这个神奇的工具也要保持一切内聚，并尽可能地将所有内容从框架移开（即让模块通过工厂处理内部依赖关系而不是依赖于框架）。在有意义的情况下将功能拆分为模块。

我正在努力改进一个通过DI框架运行所有依赖项的大型模糊应用程序，它启动缓慢，变成了一些麻烦的东西，并且使用起来不愉快，它是一个执行“一切”的应用程序，而不是将任务委托给模块和库，并且没有单元测试。

需要注意的是，每个问题都有很多解决方案，学习不同的模式是一个好主意，有很多类型的工厂模式，全部学习。有些很简单，有些更复杂，你会感觉到在不同情况下有效。

我的个人建议，如果您的应用程序按照您的意图运行，它就像听起来那样有条理，如果您还没有（并且游戏的目的是改进您的技术），请练习：

尝试使用不同的工厂加载方法，动态工厂，构建器模式，框架，使用基准来了解您交易的内容。

Answer 2

您的申请应该像这样：

$app = new Application($arg1, $arg2);
$app->run();

所有其他类应该在Application中实例化，并作为参数传递给其他类的构造函数。经验法则是：任何构造函数都应该少于3个参数。如果遵循这条规则，一切都会好的。