用Trait来导入Util函数能否作为一种解决方法?
一般对于Util方法,不外乎下面几种方法,以及我的一点看法:
- 依赖注入(好,但麻烦,且Util似乎与注入对象的主业关系不大)
- 弄一个包含Util方法的Container,然后注入(比上面那个只好一点点)
- 静态方法(static is evil)
PHP 5.4 引入了 Trait,一般来说,用它作为 Interface 的默认实现似乎受众比较多。
用 Trait 来导入 Util 函数肯定是可行的,但这种解决方法是否违背 OOP 原则?是否最佳或者“优雅”呢?我举个例子:
Trait FormatDatetimeTrait
{
proteted function formatDatetime($datetime, $style)
{
return date($style, $datetime);
}
}
好了,这个方法干的活儿似乎多余————这不是我们讨论的重点,这只是个例子。在其他类中使用这个 Trait:
Class FooBar
{
use FormatDatetimeTrait;
/** Other stuff **/
protected function getDate()
{
return $this->formatDatetime($this->time, $this->timeStyle);
}
}
我想这里 Trait 的引用还是有好处的:
- 依赖关系明了,虽然和类的主业关系不大,但毕竟用到它了
- 导入的方法可以改名(formatDatetime as formatTime)
- 客户类可以在导入函数基础之上扩展
那么,作为一种代码重用的工具,这么使用 Trait 都有那些缺点呢?是否违背 OOP 原则,或者违背它的设计初衷呢?
也欢迎有其他语言 Trait 使用经验的朋友提出宝贵意见 :-)。
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
Trait 属于静态模板(虽然可以被使用的类改写),不具备继承特性,所以不能用于继承关系比较复杂的场景。比如:
Trait 的设计就是语法糖,具备类似继承的特征,但是和继承不一样。
所以,Util 方法全部改写为 Trait 虽然一开始可行,但必定会遇到使用时的冲突,因为如果使用了 Util Trait,其他 User Trait 再使用 Util Trait,那么使用这些 User Trait 的类极易产生导入冲突。
那么,Trait 应该怎么用?当模版用!解决少量代码重复的语法糖。绝对不可以把它用作继承体系的一部分,并且要注意方法命名,尽量避免和其他类产生冲突。
最后,Trait 不可以 implement interface,PHP 这么设计还是有道理的。
原讨论: https://coding.net/u/fwolf/pp/25934
楼主,对于Trait的用途php官方文档说的很详细,你应该再仔细读读。
http://php.net/manual/zh/language.oop5.traits.php