php - 使用抽象类和静态成员更好地管理功能

Question

为了在 PHP 项目(简单 CMS)中更好地组织我的代码，我正在考虑将我的大部分系统函数作为静态成员移动到抽象类中。除了它在组织和句法上的好处之外，唯一的其他原因是将对数据源对象等的引用也存储为静态成员。

规则是用来在必要时打破的，但我想巩固我对更好(阅读最佳)模式和实践的理解。

我想这个问题是开放式的，但我想知道是否有人有任何建议，或者可以推荐一些阅读 Material ，这样我就可以探索我的选择以及什么被认为是“最佳实践”。

我的代码中的一个示例是管理权限的函数。对于任何给定的请求，可能需要进行权限检查以确保发出请求的用户具有足够的操作权限。因此，诸如 getAllPermissions()、getGroupPermissions()、addGroupPermissions() 等函数是 float 的。这些是否应该封装在 PermissionsManager 类中，这是实例化所必需的，如果是这样，我应该在哪里停止？我是否在正确的轨道上将它们作为静态方法移动到抽象类中的伪全局空间？我应该把声明留在全局范围内吗？适当的类(Class)责任在哪里结束，“神级”接管从哪里开始？我应该穿什么颜色的 socks ？

我似乎无法解决这个问题，这降低了我的工作效率。我不想再在建模上闲着了，因为尽管它有明显的好处，但我肯定已经毁掉了几棵勾勒出对象交互图的树。我的废纸篓满了。

Answer 1

suggest some reading material

看看SOLID和 GRASP和我的这个答案:Php design patterns

Should these be encapsulated within a PermissionsManager class

是的。如果这些功能相关，请将它们分组。也看看这个 Wikipedia Article about Role-Based Access Control Lists看看 various questions about ACLs in PHP on StackOverflow.

Am I on the right track moving them to a pseudo-global space within an abstract class as static methods?

不，you should avoid static if possible.静态导致紧密耦合并引入对全局范围的依赖性，导致应用程序的可维护性降低，从而导致交付时间更长(例如错误修复和新功能)，从而导致更高的总体成本和更少的投资返回。

Should I just leave the declarations in global scope?

如果您对应用程序进行了更改，您应该能够解释其好处。如果您认为您的应用程序可以从 refactoring 中受益这段代码，然后重构它。当没有投资返回时，你应该停止。

Where do appropriate class responsibilities end and 'god-class' takeovers begin?

既然你应该坚持single responsibility principle ，任何超出一个的责任都是code smell (尽管有时拥有多个可能是有意义的)。我找到了这个 description of a GodClass易于理解。

What color socks should I wear?

That depends on the shoes you intend to wear with them .一般来说，我发现深色 socks 是大多数场合和鞋子的最佳选择，而white socks are a No-Go大多数时间。

I don't want to idle any longer on modeling

在开始之前先思考一下是好的。了解问题和您要解决的领域是做出决策所必需的。但是你最终应该从解决问题开始。只有工作代码(即使是设计糟糕的代码)才能产生商业值(value)。无论如何，原始的前期设计都无法在项目的现实中生存。