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

Question

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

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

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

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

我似乎无法理解这一点，它降低了我的工作效率。我不想再在建模上闲着了，因为尽管它有明显的好处，但我确实破坏了一些绘制对象交互图的树。我的废纸篓也满了。

Answer 1

推荐一些阅读材料

看看 SOLID 和GRASP 和我的这个答案：PHP 设计模式

这些是否应该封装在 PermissionsManager 类中

是。如果这些功能相关，请将它们分组。另请参阅有关基于角色的访问控制列表的维基百科文章 并查看 StackOverflow 上有关 PHP 中的 ACL 的各种问题。

我是否走在正确的道路上，将它们作为静态方法移动到抽象类中的伪全局空间？

不，如果可能的话，您应该避免静态。静态会导致紧密耦合并引入对全局范围的依赖，从而导致应用程序的可维护性降低，从而导致交付时间更长（例如错误修复和新功能），从而导致总体成本较高，投资回报较少。

我应该将声明保留在全局范围内吗？

如果您对申请进行更改，您应该能够解释这样做的好处。如果您认为您的应用程序可以从重构此代码中受益，那么重构它。当投资没有回报时就应该停止。

适当的阶级责任在哪里结束，“神级”接管从哪里开始？

由于您应该遵守单一责任原则，因此任何超出一项的责任都是代码异味（尽管有时拥有多个代码可能是有意义的）。我发现这个对GodClass的描述很容易理解。

我应该穿什么颜色的袜子？

这取决于您打算搭配的鞋子。总的来说，我发现深色袜子是大多数场合和鞋子的最佳选择，而 大多数时候白袜子是禁忌。

我不想再闲着做模特了

。开始之前先思考一下是有好处的。了解问题和要解决的领域对于做出决策是必要的。但最终你应该从解决问题开始。只有有效的代码（即使是设计糟糕的代码）才能产生商业价值。无论如何，原始的前期设计无法在项目的现实中幸存下来。

Answer 2

作为一般建议，您应该不惜一切代价避免静态函数，至少，只要您遵循 OOP 路线。在 OOP 中，您的代码很像自然语言，函数调用遵循“主语-动词-宾语”短语结构：“某人做了某事（用其他事情）”。 “未绑定”（全局和静态）调用就像一个没有主语的短语，“这是用某物完成的”，这当然提出了一些直接的问题 - 谁是这个动作的执行者？造成的后果谁负责？为了测试目的，我们如何用其他东西替代这个动作？等等

当您遇到设计问题时，这种自然语言隐喻非常有帮助。用简单的短语写下您的问题。在主语、动词和宾语下划线。按照 $subject->verb($object) 模式用编程语言重写文本 - 瞧，你就完成了。

回到您的权限示例：您询问用户 $u 是否拥有实体 $e 的权限 $p。在自然语言中，您可以用三种不同的方式表达这一点，具体取决于您喜欢的主题：

• “Joe read foo.txt？” （主题 = 用户）
• “Joe 可以读取 foo.txt 吗？” （主题 = 实体）
• 甚至“Joe 是否已授予 foo.txt 的读取权限？” （主题 = 权限）

这三种方式听起来都不错，并且可以立即转换为 OOP-php 代码：

if ($user->can_read($file)) ...
if ($file->is_readable_by($user)) ...
if ($read_permission->for_entity($file)->is_granted_to($user)) ...

不需要静态函数。