4

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

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

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

目前流程是这样的：

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

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

4

2 回答 2

0

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

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

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

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

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

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

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

于 2012-08-29T14:09:46.530 回答
0

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

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

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

于 2012-09-07T12:59:40.147 回答