假设我为一个类编写了一个外观并公开了它的所有方法，除了它的setter。与只读接口模式有什么功能差异？
基于wikipedia article on immutable interfaces我说外观具有不可变接口的优点（当我将我的类命名为Foo而我的外观是ImmutableFoo时），而没有能够转换不可变接口的缺点“以他们具体的，可变的类型，并让他们的状态发生变异”。
修改
事实证明，维基百科上的不可变接口文章没有讨论slide 49 and 50 in this presentation中描述的只读接口模式。答案是，外观和只读界面确实可以通过使用包装类来实现，但是它们用于不同的目的（请参阅接受的答案和注释以获得更详细的观察）。
答案 0 :(得分：4)
Facade模式的主要目的不是使您的接口不可变。
来自Wikipedia：
外观是为更大的界面提供简化界面的对象 代码体，例如类库。门面可以：
- 使软件库更易于使用，理解和测试，因为外观具有方便的常用任务方法;
- 出于同样的原因，使库更具可读性;
- 减少外部代码对库内部工作的依赖性，因为大多数代码使用外观，从而允许更多 开发系统的灵活性;
- 使用一个设计良好的API（根据任务需要）包装设计糟糕的API集合。
外墙可以变形。它们用于提供简化的界面。
在你打电话给课程＆＃39; Facade＆＃39;之前，你应该问问自己，它是否提供了简化的界面并使图书馆更易于使用？
它们可能有一些重叠，但主要目的不同。
假设您正在为电子商务系统开发订单处理功能。您的核心库提供了三种方法：ChangeOrderStatus()，SendOrderToFulfillment()，SendOrderUpdateEmailToCustomer()。
如果没有外观，您必须在需要批准订单的任何地方调用所有这三种方法。它太无聊，容易犯错误。如果您将ApproveOrder()方法添加为 Facade （只需调用这三种方法），则只需在需要批准订单的地方调用ApproveOrder()即可。这简化了api，使库更易于使用。
如果您的应用程序明确分为多个层。您的基础架构层可能有一个非常薄的Facade Layer。您的所有UI代码都将与Facade层而不是基础结构层进行交互。在我的示例中，ApproveOrder()位于外观层，而ChangeOrderStatus()，SendOrderToFulfillment()，SendOrderUpdateEmailToCustomer位于基础架构层中。
某些对象应该是不可变的。例如，immutable对象通常在多线程中是首选，因为它们不会公开方法来更改其状态，因此可以安全地在线程之间共享。
从您提到的slide（第50页），＆＃34;只读界面＆＃34; pattern是一种特定的模式，可以实现＆＃34; immutable＆＃34;。但它并不是实现＆＃34; immutable＆＃34;的唯一途径。
如果您遵循特定的＆＃34;只读界面＆＃34;模式，我们可以说你实现了模式。但是如果你使用其他方法来实现＆＃34; immutable＆＃34;，我们就不能说你实现了＃34;只读接口＆＃34;模式，但你确实实现了＆＃34;不可变的＆＃34;目标。
如果实施＆＃34;只读接口＆＃34;是否重要？模式与否？当然不是，你关心＆＃34; immutable＆＃34;而不是特定的＆＃34;只读接口＆＃34;图案。 （有时，api有setter，但是如果你打电话给他们会抛出异常。这是实现＆＃34; immutable＆＃34;的另一种方式。你只需选择最合适的解决方案来实现同一目标。）< / p>