我有一个小的PHP命令行应用程序，我正在创建它来学习一些常见的设计模式和oop技术。
我已经设置了所有相关的类，这样它们就不会在内部实例化对象，而是通过构造函数为它们提供所需的对象。
现在的问题是如何编排所有内容，以便每个对象都获得所需的依赖关系。我读过关于依赖注入容器和框架的文章，但对于一个小型命令行应用程序来说，这似乎有些过头了。我很难理解它们如何适合我的应用程序。
目前的流程如下：
- 程序由用户在命令行执行
- 发生引导，即自动加载器等实例化等
- 我有一个工厂方法，它设置依赖项（所有依赖项都在类中硬编码）并返回一个应用程序对象。主应用程序大约有2个依赖项，每个依赖项又有2个（我认为这是棘手的部分）
- 调用Application->run（）
在灵活性和简单性之间取得平衡的最佳方法是什么，因为我认为（工厂周围的）设计不太正确。
从声音上看，您的应用程序组织得相当好，构建与应用程序逻辑分离，并且您的依赖关系得到了清晰的管理。
当然，您可以添加可配置的依赖项或使用依赖项注入框架，但是，我建议您避免这两种情况，除非应用程序需要。如果您确实开始使用DI框架，即使你在使用这个神奇的工具，也要确保你保持一切的凝聚力，并在可能的时候尝试将一切从框架中移除（即让模块通过工厂处理内部依赖关系，而不是依赖框架）。在合理的情况下将功能拆分为模块。
我正在改进一个大型模糊应用程序，该应用程序通过DI框架运行其所有依赖项，启动速度慢，有点像垃圾，使用起来不愉快，它是一个做"一切"的应用程序，而不是将任务委托给模块和库，并且没有单元测试。
需要注意的是，每个问题都有很多解决方案，学习不同的模式是一个好主意，有很多类型的工厂模式，都要学习。有些很简单，有些更复杂，你会对不同情况下的效果有一种感觉。
我个人的建议是，如果你的应用程序按你的意愿运行，它会按听起来的样子组织起来，如果你还没有（游戏的目的是提高你的技术），练习：
- 文档化（写一些文档并把它扔给开发人员朋友，看看他们是如何处理的）
- 测试（编写一些单元测试，然后以不同的方式重写应用程序）
- 基准测试（对代码进行评测，并尝试找到优化方法）
尝试不同的工厂加载方法，动态工厂，构建器模式，框架，使用基准来了解您的交易情况。
您的应用程序应该这样工作：
$app = new Application($arg1, $arg2);
$app->run();
所有其他类都应该在Application中实例化，并作为参数传递给其他类的构造函数。经验法则是：任何构造函数的参数都应该少于3个。如果你遵守这条规则，一切都会好起来的。