我理解的方式是,一个类永远不会打开修改.仅用于修复错误.如果我想添加新的代码到类,那么我必须创建一个新的代码,并扩展“旧”类.这是我可以添加新代码的唯一方法.
在某种程度上,我可以看到这样的优点.因为基本上你创建了一些版本控制系统,旧的代码总是可以工作,但是你总是可以尝试使用新的类.
但这在实践中如何工作？我的意思是假设我有以下类：
class MyObject
{
public function doSomething()
{
echo 'Im doing something';
}
}
所以在某个地方我可能会实例化这个类：
$obj = new MyObject();
但是,我决定在该对象中使用另一种方法是很好的.所以我也可以做别的事情根据OCP我不能修改类.所以我必须创造一个新的,延伸到旧的权利？
第一个问题我怎么称呼新班？因为它不是一个完整的新对象.喜欢. User对象是User对象.我不能突然给它完全不同的名字,因为它需要另一种方法.无论如何,我创建新的课程：
class MyNewObject extends MyObject
{
public function doSomethingElse()
{
echo 'Im doing something else Now';
}
}
现在这也意味着我必须改变代码行,我实例化了“MyObject”类,并用“MyNewObject”类替换它.如果这样做在不止一个地方完成,那么我必须搜索源代码…(想一下控制器类中的方法,几乎总是使用’new’关键字来实例化某些类).
这同样基本上适用于继承.我必须找到继承旧类的每个类,并且必须用新类替换它.
所以基本上我的问题是：
你如何命名有新方法的新课程？只是因为我添加了一些新的功能,并不意味着我可以给班级一个全新的名字…
如果“旧”类从多个地方实例化(或继承),该怎么办？那么我必须找到所有这些地方？收益在哪里？
开放原则的要点是,设计良好的系统不应要求您更改现有功能以添加新功能.如果您正在向系统添加一个新类,则不需要搜索所有代码来查找需要引用该类的地方或具有特殊情况.
如果你的类的设计不够灵活,不能处理一些新的功能,那么通过一切手段来改变你的类中的代码.但是当您更改代码时,使其变得灵活,以便将来无需更改代码即可处理类似的更改.这是一个设计策略,而不是一套手铐,以防止您进行更改.通过良好的设计决策,随着时间的推移,当您向系统添加新功能时,现有代码将需要更少和少量的更改.这是一个迭代过程.
