开闭原则背后的含义和推理是什么？

Question

开放/封闭原则规定软件实体（类、模块等）应该对扩展开放，但对修改关闭。 这意味着什么？为什么它是良好的面向对象设计的重要原则？

Answer 1

这意味着您应该将新代码放入新的类/模块中。 现有代码应仅针对错误修复进行修改。 新类可以通过继承重用现有代码。

开放/封闭原则旨在降低引入新功能时的风险。 由于您不修改现有代码，因此可以放心它不会被破坏。 它降低了维护成本并提高了产品稳定性。

Answer 2

具体来说，它是关于 OOP 中设计的“圣杯”，即使实体具有足够的可扩展性（通过其单独的设计或通过其对架构的参与）以支持未来不可预见的更改，而无需重写其代码（有时甚至无需重新编译） **）。

实现此目的的一些方法包括多态性/继承、组合、控制反转（又名 DIP）、面向方面的编程、策略、访问者、模板方法等模式以及 OOAD 的许多其他原则、模式和技术。

** 请参阅 6 个“一揽子原则”，REP、CCP、CRP、ADP、SDP、SAP

Answer 3

比 DaveK 更具体的是，它通常意味着如果您想要添加附加功能或更改类的功能，请创建一个子类而不是更改原始类。 这样，任何使用父类的人都不必担心它以后会发生变化。 基本上，这都是关于向后兼容性。

面向对象设计的另一个非常重要的原则是通过方法接口进行松耦合。 如果您想要进行的更改不会影响现有界面，那么更改确实非常安全。 例如，使算法更加高效。 面向对象的原则也需要受到常识的锻炼:)

Answer 4

让我们将问题分为三个部分，以便更容易理解各种概念。

---

开闭原则背后的推理

考虑下面代码中的示例。 不同的车辆以不同的方式进行维修。 因此，我们为 Bike 和 Car 提供了不同的类，因为服务 Bike 的策略与服务 Car 的策略不同。 Garage 类接受各种类型的车辆进行维修。

刚性问题

观察代码，看看 Garage 类在引入新功能时如何表现出刚性的迹象：

class Bike {
    public void service() {
        System.out.println("Bike servicing strategy performed.");
    }
}

class Car {
    public void service() {
        System.out.println("Car servicing strategy performed.");
    }
}

class Garage {
    public void serviceBike(Bike bike) {
        bike.service();
    }

    public void serviceCar(Car car) {
        car.service();
    }
}

正如您可能已经注意到的，每当出现某种新车辆时例如要为 Truck 或 Bus 提供服务，需要修改 Garage 来定义一些新方法，例如 serviceTruck()< /code> 和 serviceBus()。 这意味着 Garage 类必须知道每种可能的车辆，例如 Bike、Car、Bus、Truck< /代码>等等。 因此，它对修改开放，违反了开闭原则。 而且它不开放扩展，因为要扩展新功能，我们需要修改该类。

---

开闭原则背后的含义

抽象

为了解决上面代码中的僵化问题，我们可以使用开闭原则。 这意味着我们需要通过去掉 Garage 类所知道的每辆车的服务实现细节来使其变得愚蠢。 换句话说，我们应该抽象出每种具体类型（例如 Bike 和 Car）的服务策略的实现细节。

为了抽象各种类型车辆的服务策略的实现细节，我们使用一个名为 Vehicle 的接口，并在其中有一个抽象方法 service()它。

多态

同时，我们还希望Garage类能够接受多种形式的车辆，例如Bus 、卡车等等，而不仅仅是自行车和汽车。 为此，开闭原则使用了多态性（多种形式）。

为了让 Garage 类接受多种形式的 Vehicle，我们将其方法的签名更改为 service(Vehiclevehicle) { } 以接受接口 Vehicle 而不是实际的实现，如 Bike、Car 等。我们还从类中删除了多个方法，因为只有一个方法会接受多种形式。

interface Vehicle {
    void service();
}

class Bike implements Vehicle {
    @Override
    public void service() {
        System.out.println("Bike servicing strategy performed.");
    }
}

class Car implements Vehicle {
    @Override
    public void service() {
        System.out.println("Car servicing strategy performed.");
    }
}

class Garage {
    public void service(Vehicle vehicle) {
        vehicle.service();
    }
}

---

开闭原则的重要性

对修改关闭

正如您在上面的代码中看到的，现在 Garage 类已经对修改关闭了，因为现在它不知道各种类型车辆的服务策略的实施细节，并且可以接受任何类型的新车辆。 我们只需从 Vehicle 接口扩展新车辆并将其发送到 Garage 即可。 就是这样！ 我们不需要更改 Garage 类中的任何代码。

另一个关闭修改的实体是我们的 Vehicle 接口。
我们不必更改界面来扩展软件的功能。

开放扩展

Garage 类现在开放扩展，因为它将支持新类型的 Vehicle，无需进行修改。

我们的 Vehicle 接口对于扩展是开放的，因为要引入任何新的车辆，我们可以从 Vehicle 接口进行扩展，并提供一个新的实现以及服务该特定车辆的策略。

策略设计模式

你注意到我多次使用了策略这个词吗？ 那是因为这也是策略设计模式的一个示例。 我们可以通过扩展来实施不同的策略来服务不同类型的车辆。 例如，为卡车提供服务与为公共汽车提供服务的策略不同。 因此，我们在不同的派生类中实现这些策略。

策略模式使我们的软件能够随着需求随时间的变化而灵活变化。 每当客户改变策略时，只需为其派生一个新类并将其提供给现有组件，无需更改其他内容！ 开闭原则在实现这一模式中发挥着重要作用。

---

就是这样！ 希望有帮助。

Answer 5

开闭原则在面向对象编程中非常重要，它是SOLID原则之一。

据此，一个类应该对扩展开放，对扩展关闭
修改。 让我们了解原因。

class Rectangle {
    public int width;
    public int lenth;
}

class Circle {
    public int radius;
}

class AreaService {
    public int areaForRectangle(Rectangle rectangle) {
        return rectangle.width * rectangle.lenth;
    }

    public int areaForCircle(Circle circle) {
        return (22 / 7) * circle.radius * circle.radius;
    }
}

如果你看一下上面的设计，我们可以清楚地观察到它不是
遵循开闭原则。 每当有新的
形状（Tiangle，Square等），AreaService必须修改。

开闭原则：

interface Shape{
    int area();
}

class Rectangle implements Shape{
    public int width;
    public int lenth;

    @Override
    public int area() {
        return lenth * width;
    }
}

class Cirle implements Shape{
    public int radius;

    @Override
    public int area() {
        return (22/7) * radius * radius;
    }
}

class AreaService {
    int area(Shape shape) {
        return shape.area();
    }
}

每当出现三角形、正方形等新形状时，您都可以轻松
适应新的形状而不修改现有的类。 和
通过这种设计，我们可以确保现有代码不会受到影响。

Answer 6

软件实体应该对扩展开放，但对修改关闭

这意味着任何类或模块都应该以可以按原样使用、可以扩展但不能修改的方式编写，

Javascript 中的错误示例

var juiceTypes = ['Mango','Apple','Lemon'];
function juiceMaker(type){
    if(juiceTypes.indexOf(type)!=-1)
        console.log('Here is your juice, Have a nice day');
    else
        console.log('sorry, Error happned');
}

exports.makeJuice = juiceMaker;

现在如果你想添加另一个果汁，那么 type，你必须编辑模块本身，这样我们就破坏了 OCP 。

Javascript 的好例子

var juiceTypes = [];
function juiceMaker(type){
    if(juiceTypes.indexOf(type)!=-1)
        console.log('Here is your juice, Have a nice day');
    else
        console.log('sorry, Error happned');
}
function addType(typeName){
    if(juiceTypes.indexOf(typeName)==-1)
        juiceTypes.push(typeName);
}
function removeType(typeName){
  let index = juiceTypes.indexOf(typeName)
    if(index!==-1)
        juiceTypes.splice(index,1);
}

exports.makeJuice = juiceMaker;
exports.addType = addType;
exports.removeType = removeType;

现在，您可以从模块外部添加新的果汁类型，而无需编辑同一模块。

Answer 7

这是脆弱基类问题的答案，即对基类看似无害的修改可能会对依赖于先前行为的继承者产生意想不到的后果。 因此，您必须小心地封装您不希望依赖的内容，以便派生类将遵守基类定义的契约。 一旦存在继承者，您就必须非常小心在基类中所做的更改。

Answer 8

SOLID 原则中的O开放原则的目的是

1. 降低业务变更需求的成本。
2. 减少对现有代码的测试。

开闭原则指出我们应该尽量不改变现有的
添加新功能的同时编写代码。 这基本上意味着
现有代码应该对扩展开放并对扩展关闭
修改（除非现有代码中存在错误）。 在添加新功能的同时更改现有代码需要再次测试现有功能。

让我通过 AppLogger util 类来解释这一点。

假设我们需要将应用程序范围内的错误记录到名为 Firebase 的在线工具中。 因此，我们创建下面的类，并在数千个地方使用它来记录 API 错误、内存不足错误等。

open class AppLogger {

    open fun logError(message: String) {
        // reporting error to Firebase
        FirebaseAnalytics.logException(message)
    }
}

假设一段时间后，我们将支付功能添加到应用程序中，并且有一个新要求，规定仅针对与支付相关的错误必须使用名为 Instabug 的新报告工具，并像以前一样继续向 Firebase 报告包括付款在内的所有功能的错误。

现在我们可以通过在现有方法中添加 if else 条件来实现此目的。

fun logError(message: String, origin: String) {
    if (origin == "Payment") {
        //report to both Firebase and Instabug
        FirebaseAnalytics.logException(message)
        InstaBug.logException(message)
    } else {
        // otherwise report only to Firebase
        FirebaseAnalytics.logException(message)
    }
}

这种方法的问题是它违反了单一责任原则，该原则规定一个方法应该只做一件事。 另一种表达方式是一个方法应该只有一个改变的理由。 对于这种方法，有两个原因导致该方法发生变化（if 和 else 块）。

更好的方法是通过继承现有 Logger 类来创建新的 Logger 类，如下所示。

class InstaBugLogger : AppLogger() {

    override fun logError(message: String) {
        super.logError(message) // This uses AppLogger.logError to report to Firebase.
        InstaBug.logException(message) //Reporting to Instabug
    }
}

现在我们要做的就是在 Payment 功能中使用 InstaBugLogger.logError() 将错误记录到 Instabug 和 Firebase。 通过这种方式，我们可以减少/隔离新错误报告要求的测试，仅针对支付功能，因为代码更改仅在支付功能中完成。 其余的应用程序功能不需要测试，因为没有对现有记录器进行代码更改。

Answer 9

该原则意味着可以轻松添加新功能，而无需更改现有的、稳定的和经过测试的功能，从而节省时间和金钱。

通常，多态性（例如使用接口）是实现这一目标的好工具。

Answer 10

符合 OCP 的另一个经验法则是使基类相对于派生类提供的功能进行抽象。 或者正如 Scott Meyers 所说的“使非叶类抽象”。

这意味着基类中具有未实现的方法，并且仅在本身没有子类的类中实现这些方法。 那么基类的客户端就不能依赖基类中的特定实现，因为基类中没有特定的实现。

Answer 11

我只是想强调，“开放/封闭”虽然在面向对象编程中明显有用，但在开发的各个方面都是一种健康的方法。 例如，根据我自己的经验，在使用普通 C 语言时，尽可能多地使用“开/关”是一种很好的止痛药

。/Robert

Answer 12

这意味着应该构建面向对象的软件，但不应从本质上进行更改。 这很好，因为它确保了基类的可靠、可预测的性能。

Answer 13

最近，我对这一原则的含义有了更多的了解：开闭原则既描述了一种编写代码的方式，也描述了以弹性方式编写代码的最终结果。

我喜欢将开放/封闭分为两个密切相关的部分：

• 开放更改的代码可以更改其行为以正确处理其输入，或者需要最少的修改来提供新的用法场景。
• 修改关闭的代码不需要太多（如果需要）人工干预来处理新的使用场景。 这种需求根本不存在。

因此，表现出开放/封闭行为（或者，如果您愿意，满足开放/封闭原则）的代码需要进行最少的修改或无需修改，以响应超出其最初构建目的的使用场景。

至于实施方面？ 我发现通常所说的解释“开放/封闭是指代码是多态的！” 充其量只是一个不完整的陈述。 代码中的多态性是实现这种行为的一种工具。 继承、实现……实际上，每一个面向对象的设计原则对于编写按照该原则所暗示的方式具有弹性的代码都是必要的。

Answer 14

在设计原则中，SOLID——“SOLID”中的“O”代表开/闭原则。

开闭原则是一种设计原则，它规定类、模块和函数应该对扩展开放，对修改封闭。

该原则指出，代码的设计和编写应以在现有代码（经过测试的代码）中进行最少更改的情况下添加新功能的方式完成。 设计的方式应该允许添加新功能作为新类，并尽可能保持现有代码不变。

开放封闭设计原则的好处：

1. 应用程序将更加健壮，因为我们不会更改已经测试的类。
2. 灵活是因为我们可以轻松适应新的要求。
3. 易于测试且不易出错。

我对此的博客文章：

http://javaexplorer03.blogspot。在/2016/12/open-close-design-principle.html