Php 接口能定义常量,php – 接口常量的优缺点

嗯，我认为它归结为好和好之间的区别。

虽然在大多数情况下，你可以避免使用常量通过实现其他模式(策略或者flyweight)，有一些东西可以说，不需要一打其他的类来表示一个概念。我想它是什么归结到，是有可能有其他常量的需要。换句话说，是否需要扩展由接口上的常量提供的ENUM。如果你可以预见需要扩展它，然后去一个更正式的模式。如果没有，那么它可能就足够了(这将是足够好，因此更少的代码写和测试)。这里有一个足够好和坏的使用的例子：

坏：

interface User {

const TYPE_ADMINISTRATOR = 1;

const TYPE_USER = 2;

const TYPE_GUEST = 3;

}

够好了：

interface HTTPRequest_1_1 {

const TYPE_CONNECT = 'connect';

const TYPE_DELETE = 'delete';

const TYPE_GET = 'get';

const TYPE_HEAD = 'head';

const TYPE_OPTIONS = 'options';

const TYPE_POST = 'post';

const TYPE_PUT = 'put';

public function getType();

}

现在，我选择这些例子的原因很简单。用户界面正在定义用户类型的枚举。这很可能随着时间的推移而扩大，并且将更好地适应另一种模式。但HTTPRequest_1_1是一个不错的用例，因为枚举由RFC2616定义，并且不会改变类的生命周期。

一般来说，我没有看到常量和类常量作为一个全局问题的问题。我认为它是一个依赖的问题。这是一个狭窄的区别，但一个明确的。我看到全局问题，因为在全局变量，没有强制，因此创建一个软的全局依赖。但硬编码的类创建一个强制的依赖，因此创建一个硬的全局依赖。所以两者都是依赖。但我认为全局是更糟糕，因为它没有强制…这就是为什么我不喜欢块类依赖与全局依赖在同一横幅下…

如果你写MyClass :: FOO，你是硬编码到MyClass的实现细节。这创建了一个硬耦合，这使你的代码不那么灵活，因此应该避免。然而，存在接口以准确地允许这种类型的耦合。因此MyInterface :: FOO不会引入任何具体的耦合。有了说，我不会介绍一个接口，只是为它添加一个常量。

所以如果你使用的接口，你很确定你(或任何其他人为此事)将不需要额外的值，那么我真的没有看到一个巨大的问题与接口常量…最好的设计不会包括任何常量或条件或魔术数字或魔术字符串或硬编码任何东西。然而，这为开发增加了额外的时间，因为你必须考虑使用。我的观点是，大多数时候，绝对值得花费额外的时间来构建一个伟大的实体设计。但有时候，好到足以真正是可以接受的(并且需要有经验的开发人员来理解差异)，在这些情况下，它是好的。

再次，这只是我对它的看法…