如此重要的原理“OCP”是如何实现的？这会是大量代码重复实践的原因吗？

Question

OCP（开闭原则）是 SOLID 原则之一。这就是说：

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

我花了一些时间才理解上面关于 OCP 的句子。当我开始阅读更多相关内容时，我发现它很有意义并且非常有用，但同时我注意到它会导致重复的代码。

“OCP”这么重要的原则怎么会成为大量代码重复实践的原因呢？

namespace SOLIDPrinciples
 {  
    public class ReportFormatter {
        public virtual void FormatReport() {
            Console.WriteLine("Formatting Report for 8-1/2 X 11 ....");
        }
    }

    public class TabloidReportFormatter : ReportFormatter {
        public override void FormatReport() {
            Console.WriteLine("Formatting Report for 11 X 17 ....");
        }   
    }
 }

我在这里错过了什么吗？ OCP还有其他解释吗？

Answer 1

代码重复是指块、语句甚至公共成员声明分组的大量重复。它不是指语言关键字、标识符、模式等的重复。否则您将无法实现多态性。

您提供的示例并未真正演示开放/封闭原则，因为您尚未演示如何在不进行修改的情况下扩展给定类的行为。开放/封闭原则是指每次需要不同行为时创建新类。这可以使用继承和模板方法模式来实现（即调用基类中的抽象或虚拟方法，这些方法在子类中被重写以实现所需/新的行为），但更常见的是使用策略模式的组合来演示（即将变体行为封装在类中并将其传递给封闭类型以用于确定所实现的整体行为）。

从您的示例来看，您似乎更多地考虑尝试通过继承来实现 OCP，但从基本报告格式化程序开始，建立带有子类型的接口来指示给定报告的不同类型的格式实际上是一个良好的开始通过构图显示 OCP。使用基于组合的方法演示 OCP 需要一个使用格式化程序的类……比如 ReportWriter。

public class ReportWriter : IReportWriter
{
    Write(IReportData data, IReportFormatter reportFormatter)
    {
         // ...

         var formattedStream = reportFormatter.Format(data, stream);

        // ...
    }
}

只是为了演示，我对新格式化程序的行为方式做了一些假设，因此不要过分关注该部分。需要关注的是，ReportWriter 通过允许传入新的格式化程序来进行扩展，从而影响报告的最终编写方式，但对于实现这种新行为所需的代码修改（即 if 语句、switch 的存在）是关闭的。报表等多种方式实现格式化）。

开放/封闭原则不仅不会导致代码重复，当通过使用组合而不是继承来实现时，它实际上可以帮助减少重复。如果在创建继承层次结构或策略类的过程中发生真正的代码重复，那么这表明存在与您尝试实现 OCP 的上下文中可能存在的分解问题无关的问题。

Answer 2

你所拥有的对我来说看起来非常好。您没有修改 ReportFormatter，而是扩展了它。

Answer 3

类似的问题可以通过更好的方法设计来解决。请考虑以下几点：

namespace SOLIDPrincibles
 {  
    public class ReportFormatter {
        public virtual void FormatReport(String size) {
                Console.WriteLine("Formatting Report for " + size + " ....");
        }
    }

    public class TabloidReportFormatter : ReportFormatter {
        public override void FormatReport() {
                super.FormatReport("11 X 17");
        }       
    }
 }

我认为按照这些思路进行设计将是消除重复代码的最佳方法。

Answer 4

我自己实现了自定义格式报告系统，我想说这种方法已经是错误的。

当您将格式作为构造函数的参数提供时，为什么要为每种格式提供一个格式化程序类？格式化程序类构造函数（甚至是 ReportFormatter 类的静态格式化方法）应该有一个报告和一个格式描述作为参数，并相应地格式化报告。

不需要为每种格式创建一个类。

Answer 5

像这样的东西应该有效。

namespace SOLIDPrinciples
 {  
    public class ReportFormatter {
        public virtual void FormatReport() = 0;
    }

    public class VariableSizeReportFormatter : ReportFormatter {
        public void SetSize(String size);
        public override void FormatReport() {
                Console.WriteLine("implement generic layout routines");
        }       
    }

    public class TabloidReportFormatter : VariableSizeReportFormatter {
        public override void FormatReport() {
                // currently, we just do a tweaked version of generic layout ..
                SetSize("11x7");
                Super.Format(); 
                Console.WriteLine("RemoveThatColumnWeDontWant");
        }       
    }
 }

这意味着：

• ReportFormatter 的客户端不需要更改（假设其他地方有一些处理设置的机制）。
• 可以添加对通用格式化功能的改进来改进所有报告，因此没有重复的代码，
• 您只需要在某些特定情况下更好地工作，您可以进行更改

这是关键的第三点：您可以说“在原则上，如果注释使行太大而无法容纳，智能布局例程应该知道从日期中删除年份。但在实践中实施这一更改可能是一场噩梦，如果这意味着其他报告会出现错误，因此您必须更改其工作原理，然后重新测试系统中的每个报告布局......