什么依赖策略适合这个小应用

Posted 2023-03-31

【中文标题】什么依赖策略适合这个小应用

【英文标题】：What dependency strategy suits this small app

【发布时间】：2012-08-20 08:20:06

【问题描述】：

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

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

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

目前流程是这样的：

程序由用户在命令行执行 发生引导，即自动加载器等实例化等 我有一个工厂方法，它设置依赖项（所有硬编码在类中）并返回一个应用程序对象。主应用程序大约有 2 个依赖项，每个依赖项都有另外 2 个依赖项（我认为这是棘手的部分） Application->run() 被调用。

就灵活性和简单性之间的平衡而言，最好的方法是什么，因为我不认为设计（围绕工厂）是完全正确的。

【问题讨论】：

也许你可以从这个链接得到一些想法：fabien.potencier.org/article/50/…

工厂方法是正确的。归根结底，必须做一些事情来实例化对象并建立它们之间的关系。这样做的东西是工厂。

【参考方案1】：

从听起来你的应用程序组织得很好，构造与应用程序逻辑是分开的，并且你的依赖关系得到了清晰的管理。

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

我正在对一个大型模糊应用程序进行改进，该应用程序通过 DI 框架运行其所有依赖项，启动速度很慢，并且变得有点废话，使用起来不愉快，它是一个执行“一切”而不是将任务委托给模块和库的应用程序，并且具有零单元测试。

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

我的个人建议，如果您的应用程序按您的预期运行，它的组织方式与听起来一样，如果您还没有（并且游戏的目的是提高您的技术），请练习：

记录（编写一些文档并将其交给开发者朋友，看看他们是如何处理的） 测试（编写一些单元测试，然后以不同的方式重写应用程序） 基准测试（对您的代码运行分析并尝试找到优化它的方法）

尝试不同的方法来加载工厂、动态工厂、构建器模式、框架，使用基准来了解您权衡了什么。

【参考方案2】：

您的应用程序应该像这样工作：

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

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