我正在开发一个使用帮助程序类的Web应用程序。这些类包含各种操作的功能，如表单处理。
有时我在我的应用程序中的多个位置需要这些类，我现在的方法是创建一个新的Object。我无法传递变量，这将是太多的工作。
我想知道为此使用单例类。这样我确信一次只运行一个实例。
我的问题是，当我使用这个模式时，如果我为所有对象创建一个单例类，这将会进行大量的代码复制。
我可以改为创建一个superHelper的超类，它是一个单例类，然后让每个帮助器扩展它。
这种设置是否有效，还是有另一种选择？
如果它有效，是否有人对如何编写这样的superHelper类有任何建议。
谢谢你们
答案 0 :(得分：0)
我无法传递变量，这将是太多的工作。
你确定吗？人们倾向于过高估计传递依赖关系的努力。如果你在构造函数中执行它，通常很简单。
也就是说，你可以在php中以不同的方式将共享功能放在全局范围内。最简单的是使用全局函数。例如。一个不属于任何类的函数。另一种选择是使用静态类方法。这两个非常相似;除了它们的语法，它们基本上具有相同的属性。稍微松散耦合的解决方案是将功能作为一种方法放在（抽象）基类上，这是您的具体类扩展而来的。这在所有子类之间共享功能。
上述解决方案的共同点是它们具有编译时耦合。您无法在运行时更改依赖关系，这会使您的应用程序变得非常严格。它们的主要好处是它们带来的复杂程度很低。
如果你想要一个更松散耦合的应用程序，你可以尝试用一个变量替换硬依赖，以提供一个间接级别。简单的方法是创建一个对象，并在整个应用程序中全局共享。在PHP中有很多方法可以做到这一点，例如单例或全局范围内的变量（可以使用global关键字或$GLOBALS数组）来访问它。 / p>
虽然全局变量提供了一定程度的间接性，但它们也往往会引入很多复杂性，因为它们很难弄清楚应用程序的哪些部分相互依赖。出于这个原因，经验丰富的程序员经常会避免使用它们。如果变量具有状态，则尤其如此;如果共享对象是无状态的，那么问题就不那么普遍了。
避免全局变量危险的唯一方法是使用局部变量。例如。传递依赖关系。这可能有点麻烦，但根据我的经验，它往往不是那么大的问题。至少，好处往往超过问题。也就是说，有一些技巧可以缓解疼痛;特别是依赖注入容器，它是自动工厂，为您处理所有的布线。虽然它们具有自己的复杂程度，但对于更大的应用程序，它们肯定是一个很好的解决方案。
答案 1 :(得分：0)
答案 2 :(得分：0)
您无法扩展单例类。请记住，在单例类中，我们将构造函数设为私有，因此如果构造函数是私有的，那么如何扩展此类？我们都知道我们创建了一个类的对象，我们称之为构造函数，在子类构造函数中它隐式地调用了父构造函数。因此，在这种情况下，无法在子类中调用私有构造函数。
答案 3 :(得分：-1)
虽然有时候必要，但是单身人士是邪恶的（因为他们是全球状态）。如果你能提供帮助，尽量避免使用它们。
编辑：如果你无法避免单身，至少参数化对该状态的引用。换句话说，在类中，将单例传递给它的构造函数或那些使用单例的方法。
简单地将代码库中的引用引用到单例中将会影响您单独测试类的能力。
如果您的单身人士有状态，您的测试将突然变为有状态，并且您的测试可以开始“级联失败”，因为他们的先决条件会因先前的测试失败而被破坏。