最近我一直在努力学习PHP,我发现自己被trait缠住了。我理解横向代码重用的概念,并且不希望必然地继承抽象类。我不明白的是:使用特征和使用界面之间的关键区别是什么?
我曾试着搜索过一篇像样的博客文章或文章,解释什么时候使用其中一种或另一种,但到目前为止,我找到的例子似乎非常相似,甚至完全相同。
最近我一直在努力学习PHP,我发现自己被trait缠住了。我理解横向代码重用的概念,并且不希望必然地继承抽象类。我不明白的是:使用特征和使用界面之间的关键区别是什么?
我曾试着搜索过一篇像样的博客文章或文章,解释什么时候使用其中一种或另一种,但到目前为止,我找到的例子似乎非常相似,甚至完全相同。
当前回答
基本上,您可以将trait视为代码的自动“复制-粘贴”。
使用trait是很危险的,因为在执行前我们无法知道它的作用。
然而,由于缺乏遗传等限制,性状更加灵活。
trait在注入方法时很有用,它可以检查类中是否存在另一个方法或属性。这是一篇不错的文章(但是是法语,抱歉)。
对于能读法语的人来说,GNU/Linux杂志HS 54有一篇关于这个主题的文章。
其他回答
描述trait的一个常用比喻是:trait是带有实现的接口。
在大多数情况下,这是一种很好的思考方式,但两者之间存在一些微妙的差异。
首先,instanceof操作符不能与trait一起工作(即,trait不是一个真正的对象),因此不能使用它来查看一个类是否具有某个trait(或者查看两个本来不相关的类是否共享一个trait)。这就是他们所说的横向代码重用的结构。
现在PHP中有一些函数可以让您获得类使用的所有特征的列表,但是特征继承意味着您需要进行递归检查,以可靠地检查类在某个时刻是否具有特定的特征(PHP doco页面上有示例代码)。不过,它当然不像instanceof那样简单干净,以我之见,这个特性会让PHP变得更好。
而且,抽象类仍然是类,因此它们不能解决与多重继承相关的代码重用问题。请记住,您只能扩展一个类(真实的或抽象的),但可以实现多个接口。
我发现trait和接口非常适合一起使用来创建伪多重继承。例如:
class SlidingDoor extends Door implements IKeyed
{
use KeyedTrait;
[...] // Generally not a lot else goes here since it's all in the trait
}
这样做意味着您可以使用instanceof来确定特定的Door对象是否是Keyed的,您知道您将得到一组一致的方法,等等,并且所有的代码在所有使用KeyedTrait的类中都位于一个位置。
公共服务公告:
我想要声明的是,我相信trait几乎总是一种代码气味,应该避免使用组合。在我看来,单继承经常被滥用到反模式的地步,而多重继承只会加剧这个问题。在大多数情况下,使用组合而不是继承(无论是单个还是多个)会更好。如果您仍然对特征及其与界面的关系感兴趣,请继续阅读…
让我们这样开始:
面向对象编程(OOP)可能是一个难以掌握的范例。 仅仅因为你在使用类并不意味着你的代码就是 面向对象(OO)。
要编写OO代码,你需要理解OOP实际上是关于对象的功能。你必须考虑类可以做什么,而不是它们实际做什么。这与传统的过程式编程形成了鲜明的对比,在传统的过程式编程中,重点是让一小段代码“做一些事情”。
如果面向对象编程是关于规划和设计的,那么接口就是蓝图,对象就是完全建成的房子。与此同时,特征只是一种帮助建造蓝图(界面)所布置的房子的方法。
接口
那么,我们为什么要使用接口呢?很简单,接口使我们的代码不那么脆弱。如果您怀疑这种说法,可以问问那些被迫维护遗留代码的人,这些代码不是针对接口编写的。
接口是程序员和他/她的代码之间的契约。这个界面说:“只要你遵守我的规则,你可以随心所欲地实现我,我保证不会破坏你的其他代码。”
举个例子,考虑一个现实世界的场景(没有汽车或小部件):
你想为一个web应用程序实现一个缓存系统 服务器负载下降
你开始写一个类来缓存请求响应使用APC:
class ApcCacher
{
public function fetch($key) {
return apc_fetch($key);
}
public function store($key, $data) {
return apc_store($key, $data);
}
public function delete($key) {
return apc_delete($key);
}
}
然后,在HTTP响应对象中,在执行生成实际响应的所有工作之前检查缓存命中:
class Controller
{
protected $req;
protected $resp;
protected $cacher;
public function __construct(Request $req, Response $resp, ApcCacher $cacher=NULL) {
$this->req = $req;
$this->resp = $resp;
$this->cacher = $cacher;
$this->buildResponse();
}
public function buildResponse() {
if (NULL !== $this->cacher && $response = $this->cacher->fetch($this->req->uri()) {
$this->resp = $response;
} else {
// Build the response manually
}
}
public function getResponse() {
return $this->resp;
}
}
这种方法非常有效。但也许几周后你决定使用基于文件的缓存系统而不是APC。现在你必须改变你的控制器代码,因为你已经把你的控制器编程为使用ApcCacher类的功能,而不是一个表达ApcCacher类功能的接口。让我们假设你让Controller类依赖于CacherInterface而不是具体的ApcCacher,就像这样:
// Your controller's constructor using the interface as a dependency
public function __construct(Request $req, Response $resp, CacherInterface $cacher=NULL)
你可以这样定义你的界面:
interface CacherInterface
{
public function fetch($key);
public function store($key, $data);
public function delete($key);
}
反过来,你让你的ApcCacher和你的新FileCacher类实现CacherInterface,你编程你的Controller类来使用接口所需的功能。
这个示例(希望)演示了如何通过接口编程来更改类的内部实现,而不用担心这些更改是否会破坏其他代码。
特征
另一方面,trait只是一种重用代码的方法。界面不应该被认为是与特征相排斥的选择。事实上,创建满足接口所需功能的特征是最理想的用例。
只有当多个类共享相同的功能(可能由相同的接口决定)时,才应该使用trait。使用trait为单个类提供功能是没有意义的:这只会混淆类的功能,更好的设计应该将trait的功能移到相关的类中。
考虑下面的trait实现:
interface Person
{
public function greet();
public function eat($food);
}
trait EatingTrait
{
public function eat($food)
{
$this->putInMouth($food);
}
private function putInMouth($food)
{
// Digest delicious food
}
}
class NicePerson implements Person
{
use EatingTrait;
public function greet()
{
echo 'Good day, good sir!';
}
}
class MeanPerson implements Person
{
use EatingTrait;
public function greet()
{
echo 'Your mother was a hamster!';
}
}
一个更具体的例子:假设接口讨论中的FileCacher和ApcCacher都使用相同的方法来确定缓存项是否过时,是否应该删除(显然在现实生活中不是这样的,但还是这样吧)。您可以编写一个trait,并允许两个类使用它来满足公共接口需求。
最后提醒一句:注意不要在性格特征上走极端。当独特的类实现就足够了的时候,特征常常被用作糟糕设计的拐杖。为了获得最佳的代码设计,你应该限制特征以满足界面需求。
trait本质上是PHP对mixin的实现,实际上是一组扩展方法,可以通过添加trait将其添加到任何类中。然后,这些方法成为该类实现的一部分,但不使用继承。
来自PHP手册(强调我的):
trait是单继承语言(如PHP. ...)中代码重用的一种机制它是对传统继承的补充,并支持行为的水平组合;也就是说,类成员的应用不需要继承。
一个例子:
trait myTrait {
function foo() { return "Foo!"; }
function bar() { return "Bar!"; }
}
有了上面的特征,我现在可以做以下事情:
class MyClass extends SomeBaseClass {
use myTrait; // Inclusion of the trait myTrait
}
在这一点上,当我创建一个MyClass类的实例时,它有两个方法,称为foo()和bar()——它们来自myTrait。注意,trait定义的方法已经有一个方法体,而接口定义的方法没有。
此外,PHP与许多其他语言一样,使用单一继承模型——这意味着一个类可以从多个接口派生,但不能从多个类派生。但是,PHP类可以包含多个trait——这允许程序员包含可重用的部分——就像包含多个基类一样。
有几件事需要注意:
-----------------------------------------------
| Interface | Base Class | Trait |
===============================================
> 1 per class | Yes | No | Yes |
---------------------------------------------------------------------
Define Method Body | No | Yes | Yes |
---------------------------------------------------------------------
Polymorphism | Yes | Yes | No |
---------------------------------------------------------------------
多态:
在前面的例子中,MyClass扩展了SomeBaseClass, MyClass是SomeBaseClass的一个实例。换句话说,像SomeBaseClass[] bases这样的数组可以包含MyClass的实例。类似地,如果MyClass扩展了IBaseInterface,则IBaseInterface[]基数组可以包含MyClass的实例。trait不存在这样的多态结构——因为trait本质上只是为了程序员方便而复制到每个使用它的类中的代码。
优先级:
如手册所述:
从基类继承的成员被Trait插入的成员覆盖。优先级顺序是当前类的成员重写Trait方法,Trait方法反过来重写继承的方法。
所以,考虑下面的场景:
class BaseClass {
function SomeMethod() { /* Do stuff here */ }
}
interface IBase {
function SomeMethod();
}
trait myTrait {
function SomeMethod() { /* Do different stuff here */ }
}
class MyClass extends BaseClass implements IBase {
use myTrait;
function SomeMethod() { /* Do a third thing */ }
}
当创建MyClass的实例时,会发生以下情况:
Interface IBase需要提供一个名为SomeMethod()的无参数函数。 基类BaseClass提供了该方法的实现—满足需求。 trait myTrait也提供了一个名为SomeMethod()的无参数函数,它优先于baseclass版本 类MyClass提供了它自己的SomeMethod()版本-它优先于特征版本。
结论
Interface不能提供方法体的默认实现,而trait可以。 接口是一种多态的、可继承的结构,而特征则不是。 在同一个职业中可以使用多个接口,也可以使用多个特征。
基本上,您可以将trait视为代码的自动“复制-粘贴”。
使用trait是很危险的,因为在执行前我们无法知道它的作用。
然而,由于缺乏遗传等限制,性状更加灵活。
trait在注入方法时很有用,它可以检查类中是否存在另一个方法或属性。这是一篇不错的文章(但是是法语,抱歉)。
对于能读法语的人来说,GNU/Linux杂志HS 54有一篇关于这个主题的文章。
接口定义了实现类必须实现的一组方法。
当trait被使用时,方法的实现也会出现——这在接口中不会发生。
这是最大的不同。
PHP RFC的水平重用:
trait是一种在单继承语言(如PHP)中代码重用的机制。Trait旨在通过允许开发人员在不同类层次结构中的几个独立类中自由地重用方法集来减少单个继承的一些限制。