PHP中静态方法的缺点
|
在一个理论数据库访问类中,我发现我在类中使用了很多辅助函数,这些函数与类的实例没有任何关系(以及其他可以使用依赖注入操作与类的实例无关的实例) ).
例如,我有一个函数,它在变量中的两个其他字符串之间获取一个字符串.我一直在考虑将它移动到String_Helper类,或类似的东西.此功能已经变为静态. 另外,我有一个查询数据库,查询($sql)的函数.连接细节由实例提供,但我一直在考虑将其设置为静态,并使用查询($sql,$connection).然后开发人员可以静态地调用它,而根本不需要实例化数据库类. 对我来说,问题是： >做这样的事情值得吗？像查询函数这样的函数让我想知道这不仅仅是我试图让一切尽可能地保持静态,而没有任何实际需要.在什么情况下你会认为这有用吗？
好的,让我逐一回答这些问题……
1.值得做这样的事情 是的,不是.将辅助函数拆分成自己的类是个好主意.它保持每个类的“范围”严格定义,并且你不会得到坍塌.但是,不要因为可以使方法静态.查询方法是通过管理连接使您的生活更轻松,那么为什么您想要失去这种好处？ 他们更难测试 它们并不难测试.依赖于状态的静态方法更难测试(访问静态成员变量或全局变量).但是静态方法通常和实例方法一样容易测试(事实上,它们可以更容易,因为您不需要担心实例化). 3.扩展课程 这是一个有效的问题.如果你把String_Helper :: foo()放在类本身,你会遇到问题.但是一个选项是将字符串帮助器的名称设置为类变量.那么你可以做{$this-> stringHelper} :: foo()(注意,仅限PHP 5.3).这种覆盖类的方法,您需要做的就是更改该实例中的字符串帮助程序类. 4.全球登记处 我会远离这个.你基本上只是让每个班级都成为单身人士而不强制执行.由于您现在依赖于全球范围,测试将是一场噩梦.相反,我将创建一个注册表对象,并通过构造函数(依赖注入)将其传递给类.您仍然可以完成同样的事情,因为您有一个对象/类的存储,但您不再依赖于全局范围.这使测试更容易. 一般来说 当你正在考虑做这样的事情时,我喜欢在遇到这样的问题时停下来.停下来坐下来思考*我试图解决的是什么实际问题？“.明确列举问题.然后拉出你想要的解决方案,看看他们是否真的解决了问题.如果他们这样做了,那就考虑一下未来以及是否有解决方案从长远来看是非常可维护的(从错误修复的角度来看,以及关于功能添加的内容).只有当你对这两个答案感到满意时,你才应该考虑这样做.哦,还记得保持简单编程不是要制作最复杂,最聪明或最神奇的解决方案.它是关于制作解决问题的最简单的解决方案…… 我希望有帮助…… 祝好运！ （编辑：李大同） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |