Façade 是否利用了开闭原则？答案

【问题标题】：Does Façade leverage the Open-Closed Principle?Façade 是否利用了开闭原则？
【发布时间】：2013-02-27 20:33:18
【问题描述】：

开闭原则的Wikipedia page（截至今天2013-02-27）说它是通过继承实现的。

开放/封闭原则这个名称有两种使用方式。两种方式都使用继承来解决明显的困境，但目标、技术和结果不同。

“两种方式”是指 Meyer 的实现继承和更常见的多态扩展。

无论如何，我的问题是关于Façade 模式，它不使用继承。既然它以简化接口的形式定义了一个对更复杂的子系统（或库）的抽象，难道这也不能被看作是开闭原则吗？更具体地说：

子系统（或库）对扩展开放到使用 Façade 的客户端，其接口对修改关闭。

或者我只是在扩展信息隐藏的界限（这非常接近 OCP，尤其是如果您将其视为 Protected Variations）。

【问题讨论】：

标签： design-patterns solid-principles facade open-closed-principle

【解决方案1】：

不，Facade 模式解决的问题与 OCP 不同。 Facade 只是一个类，它是其他一些类的前面。 Facade 将它的客户与它所面对的类的变化隔离开来，但这不是 OCP。 OCP 是关于各个类如何响应需求变化而变化的。没有任何关于 Facade 的设置来引导这些更改。如果客户对立面的要求发生变化，立面也会发生变化。如果 Facade 面向的任何类以 Facade 关心的方式发生变化，Facade 也会如此。

人们可以想象一个按照 OCP 设置的 Facade 版本——也许是一个 Facade，其与客户端的接口是一个接口或抽象类，它对修改是封闭的，但可以扩展以适应新的需求——事实上我一直以这种方式实现 Facade，但这不是 Facade 的经典描述的一部分。

【讨论】：

不明白，If client's requirements on Facade change, so will the Facade.客户端禁止修改；战略也会因此而崩溃。 If any of the classes that the Facade fronts for change in ways that the Facade cares about, so will the Facade. -- 但是外观的隐藏部分发生了变化。 OCP == member variables private in a class.
我将 Facade 视为不稳定（类似私有）子系统的稳定接口。至于必须有一个接口或抽象类，我不确定。 JOptionPane 是我最喜欢的 Facade 示例。它不是抽象类/接口。它的公共部分不会很快改变（除了可能添加方法）。
我想了一会儿，还没有想出任何话来解释我还没有说过的立场。如果我有什么想法，我会回来的。