为了更好地组织PHP项目(一个简单的CMS)中的代码,我正在考虑将大多数System函数作为静态成员移至抽象类.除了从中获得组织和语法上的好处外,唯一的其他原因是将对数据源对象等的引用存储为静态成员.
在必要时可以打破规则,但是我想巩固我对更好(最好阅读)的模式和实践的理解.
我想这个问题是开放性的,但是我想知道是否有人提出建议,或者可能建议一些阅读材料,因此我可以探讨自己的选择以及被认为是“最佳实践”的东西.
我的代码中的一个示例是用于管理权限的函数.对于任何给定的请求,可能需要进行权限检查,以确保发出请求的用户具有足够的操作特权.因此,诸如getAllPermissions(),getGroupPermissions(),addGroupPermissions()等的函数随处可见.是否应该将它们封装在实例化必需的PermissionsManager类中,如果是这样,我应该在哪里停下来？我是否在正确的轨道上将它们作为静态方法移动到抽象类中的伪全局空间中？我应该只将声明保留在全局范围内吗？适当的阶级责任在哪里结束,“神职”接管从哪里开始？我应该穿什么颜色的袜子？
我似乎无法解决这个问题,并且这降低了我的生产率.我不想再花时间在建模上,因为尽管有明显的好处,但我肯定已经破坏了几棵树来绘制对象交互图.我的废纸bas已满.
解决方法:
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.静态函数会导致紧密耦合并引入对全局范围的依赖性,从而导致应用程序的维护性较差,从而导致较长的交付时间(例如错误修正和新功能),从而导致更高的总体成本和更少的投资回报.
如果您对应用程序进行了更改,则应该能够解释其好处.如果您认为您的应用程序可以从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.总的来说,我发现深色袜子是大多数场合和鞋子的最佳选择,而大多数时候是white socks are a No-Go.
I don’t want to idle any longer on modeling
开始之前先思考一下是好事.了解问题和您要解决的领域是做出决定所必需的.但是您应该首先解决问题.只有有效的代码(甚至设计不佳的代码)也会产生商业价值.无论如何,原始的前期设计无法在项目中生存.
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 dio@foxmail.com 举报，一经查实，本站将立刻删除。
