为了更好地在PHP项目（简单 CMS）中组织我的代码，我正在考虑将我的大多数系统函数作为静态成员移动到抽象类中。除了组织和语法上的好处之外，唯一的另一个原因是将对数据源对象等的引用存储为静态成员。
规则在必要时会被破坏，但我希望巩固我对更好（阅读最佳）模式和实践的理解。
我认为这个问题是开放性的，但我想知道是否有人有建议，或者可能会提出一些阅读材料，所以我可以探索我的选择以及被认为是“最佳实践”。
我的代码中的一个例子是用于管理权限的函数。对于任何给定的请求，可能需要进行权限检查以确保请求用户具有足够的操作权限。因此，诸如getAllPermissions()，getGroupPermissions()，addGroupPermissions()等功能正在浮动。这些是否应该封装在PermissionsManager类中，这是实例化所必需的，如果是，我应该在哪里停止？我是否在正确的轨道上将它们作为静态方法移动到抽象类中的伪全局空间？我应该将声明留在全球范围内吗？适当的阶级责任在哪里结束，“上帝级”的收购从哪里开始？我应该穿什么颜色的袜子？
我似乎无法绕过这个，这会降低我的工作效率。我不想再在建模上闲置了，因为尽管它有明显的好处，但我确实摧毁了一些草绘出对象交互图的树。我的废纸篓已经满了。
答案 0 :(得分：3)
提出一些阅读材料
请查看SOLID和GRASP以及我的答案：Php design patterns
这些是否应封装在PermissionsManager类
中
是。如果这些功能相关，请将它们分组。另请查看此Wikipedia Article about Role-Based Access Control Lists并查看various questions about ACLs in PHP on StackOverflow.
我是否在正确的轨道上将它们作为静态方法移动到抽象类中的伪全局空间？
不，you should avoid static if possible.静态导致紧密耦合并引入全局范围的依赖性，导致可维护性较低的应用程序导致更长的交付时间（例如错误修正和新功能），从而导致更高的总体成本和更少的投资回报。
我应该将声明留在全球范围内吗？
如果您对应用程序进行了更改，您应该能够解释其中的好处。如果您认为您的应用程序可以从refactoring此代码中受益，那么请重构它。当没有投资回报时，你应该停止。
适当的职业责任在哪里结束，'上帝级'的接管开始了？
既然你应该坚持single responsibility principle，那么除了code smell之外的任何责任都是description of a GodClass（尽管有时候不止一个也有意义）。我发现这个That depends on the shoes you intend to wear with them很容易理解。
我应该穿什么颜色的袜子？
white socks are a No-Go。一般来说，我发现深色袜子是大多数场合和鞋子的最佳选择，而{{3}}大部分时间都是。
我不想再建模
了
在你开始之前的一些想法是好的。了解问题和您要解决的域是制定决策所必需的。但是你应该从最终解决问题开始。只有工作代码（即使是设计不佳的代码）才能产生商业价值。无论如何，原始的前期设计都无法在项目的实际环境中存活下来。
答案 1 :(得分：1)
作为一般建议，只要遵循OOP路线，至少应该以任何价格避免静态功能。在OOP中，你的代码很像一种自然语言，函数调用遵循“主语 - 动词 - 宾语”的短语结构：“有人做某事（带别的东西）”。 “未绑定”（全局和静态）调用就像一个没有主题的短语，“这是用某些东西完成的”，当然，这会引发一些直接的问题 - 谁是这个行动的主角？谁对后果负责？为了测试目的，我们如何用其他东西替换这个动作呢？等等
当您遇到设计问题时，这种自然语言隐喻非常有用。用简单的短语写下你的问题。强调主题，动词和对象。按照$subject->verb($object)模式用编程语言重写文本 - vo vo，，你已经完成了。
回到您的权限示例：您询问用户$ u是否拥有实体$ e的权限$ p。在自然语言中，您可以通过三种不同的方式表达这一点，具体取决于您希望成为主题的内容：
这三种方式听起来都不错，可以立即翻译成OOP-php代码：
if ($user->can_read($file)) ...
if ($file->is_readable_by($user)) ...
if ($read_permission->for_entity($file)->is_granted_to($user)) ...
不需要静态功能。