PHP MVC：将实用程序/帮助程序类实例作为依赖项注入基类

Question

在我的 HMVC 项目中，我实现了一个 Arrays 类。它的 STATIC 方法总体上用于处理多维数组上的各种操作。除了这个类，我也使用类似的类：Files、Images、Printer、Messages、Classes 等。但我不想再在我的项目中使用任何静态或单例了。

我将它们视为助手，最终类具有用于仅在项目组件上或与它们一起执行特定任务的方法（合并数组、调整图像大小、上传/打印文件等）。因此，我想...尽量减少它们在我的项目中的分布。

例如，我认为在每个子控制器中传递 Arrays 对象并不是最佳选择，因为在基本控制器类的构造函数中必须合并一些数组。

我想问一下：

• 我实际上在基本控制器类中合并数组是错误的，还是真的会出现这种情况？
• 如果没有错，那么我只能选择将实用程序类Arrays作为构造函数依赖传递，而static问题将通过这种方式优雅地解决。这是真的吗，还是有更好的选择？

我会很感激你的任何观点。

非常感谢！

---

附注：

这是Arrays类，如果你需要看一下：

<?php

namespace MYMVC\Utils;

/**
 * Arrays: utility class to handle operations on multidimensional arrays.
 */
class Arrays {

    /* ------------------------------------------------------------- */
    /* Keypath format: '{key0}/{key1}/{key2}/{key3}/{searched-key}'. */
    /* ------------------------------------------------------------- */

    /** Set the value in array at the specified keypath. [...] */

    public static function setArrayValue(&$array, $keypath, $value, $delimiter = '/') { ... }


    /** Get a tree structure from the specified keypath. [...] */

    public static function buildArrayTree($keypath, $value, $delimiter = '/') { ... }


    /** Check if the specified keypath exists in array. [...] */

    public static function arrayKeyExists(&$array, $keypath, $delimiter = '/') { ... }


    /** Get the array value from the specified keypath. [...] */

    public static function getArrayValue(&$array, $keypath, $delimiter = '/') { ... }


    /** Merge multiple multidimensional arrays. [...] */

    public static function mergeMultipleArrays(/* func_get_args */) { ... }


    /** Merge the top multidimensional array over the base multidimensional array. [...] */

    public static function mergeArrays($base, $top) { ... }

}

Answer 1

Arrays::mergeArrays 之类的东西没有错。你不介意在你的课堂上打电话给in_array 或array_merge，不是吗？如果您愿意，您可以将 Arrays 称为“实用程序”类，但我认为您不能为 Files 做同样的事情。

如果您当前的问题是“我不想将 xyz 对象传递给每个子控制器”，那么通常您会有以下想法：

• 只需将 DIC 注入您的控制器即可。然后从中检索您的依赖项。这就是所谓的“服务定位器”，它被许多框架广泛使用。它的优点是您可以仅在需要时才需要依赖项。但它有一系列的缺点。没有它你的对象就不能存在，你的类也不能轻易地被嘲笑。这就是为什么它被认为是一种反模式。

• 在控制器中显式注入您的依赖项（即：Files）。为什么要隐藏控制器依赖于Files 的事实？这里唯一的问题是，尤其是对于控制器，许多依赖项并不总是被所有类的方法使用。这更像是一个性能问题，您可以考虑通过多种方式解决它（例如： Action object)。

选择适合你的。