0

Say I write a facade for a class and expose all it's methods except for it's setters. What is the functional difference with the read-only interface pattern?

Based on the wikipedia article on immutable interfaces I'd say the facade has the advantages of the immutable interface (when I name my class Foo and my facade is ImmutableFoo) while not having the disadvantage of being able to cast the immutable interface "to their concrete, mutable type, and have their state mutated".

EDIT

As it turns out the immutable interface article on Wikipedia doesn't talk about the read-only interface pattern, which is described on slide 49 and 50 in this presentation. The answer is that both facade and the read-only interface can indeed be achieved by using a wrapper class, however they serve different purposes (see the accepted answer and comments for a more detailed observation).

user8363
  • 1,299
  • 3
  • 13
  • 17

1 Answers1

4

The main purpose of Facade pattern is not to make your interfaces immutable.

From Wikipedia:

A facade is an object that provides a simplified interface to a larger body of code, such as a class library. A facade can:

  • make a software library easier to use, understand and test, since the facade has convenient methods for common tasks;
  • make the library more readable, for the same reason;
  • reduce dependencies of outside code on the inner workings of a library, since most code uses the facade, thus allowing more flexibility in developing the system;
  • wrap a poorly designed collection of APIs with a single well-designed API (as per task needs).

Facades can be mutable. They are used to provide a simplified interface.

Before you call a class a 'Facade', you should ask yourself, does it provides a simplified interface and make the library easier to use?

They might have some overlap, but the main purposes are different.

Facade Is About API Simplification

Say you are developing an order processing feature for an Ecommerce system. Your core library provides three methods: ChangeOrderStatus(), SendOrderToFulfillment(), SendOrderUpdateEmailToCustomer().

Without a facade, you have to call all these three methods wherever you need to approve an order. It's so boring and easy to make mistakes. If you add an ApproveOrder() method as a Facade (which simply calls that three method), you will only need to call ApproveOrder() wherever you need to approve an order. This simplify the api, and make the library easier to use.

If your application is clearly split into multiple layers. You might have a very thin Facade Layer on top of your infrastructure layer. All your UI code will interact with the facade layer instead of the infrastructure layer. In my example, ApproveOrder() is in the facade layer, while ChangeOrderStatus(), SendOrderToFulfillment(), SendOrderUpdateEmailToCustomer are in the infrastructure layer.

Read-only Interface Is About Data Protection

Some objects are supposed to be immutable. For example, immutable objects are often preferred in multi-threading, because they don't expose methods to change their states, so they are safe to be shared among threads.

Pattern vs. Goal

From the slide (page 50) you mentioned, the "Read-only Interface" pattern is a specific pattern to achieve "immutable". But it's not the only way to achieve "immutable".

If you follow the specific "Read-only Interface" pattern, we can say you implement the pattern. But if you use some other approach to achieve "immutable", we can't say you implement the "Read-only Interface" pattern, but you do achieve the "immutable" goal.

Does it matter if you implement the "Read-only Interface" pattern or not? Of course not, you care about "immutable", not the specific "Read-only Interface" pattern. (Sometimes, the api has setters, but they will throw exceptions if you call them. This is another way to achieve "immutable". You just have to choose the most suitable solution to achieve a same goal.)

Community
  • 1
  • 1
Mouhong Lin
  • 4,402
  • 4
  • 33
  • 48
  • Isn't the immutable interface a simplified interface of the original class? Where the the original has getters and setters, the interface has only getters, thus a simplified version of the original. Could you say that the _implementation_ of creating another class with restricted access to the original as is usually done to achieve _the intent of the facade pattern_ would in this case achieve _the intent of the read-only interface pattern_? Is there any **functional** difference? – user8363 Mar 18 '15 at 14:19
  • to conclude: Design patterns are descriptions to solve a particular problem, they say nothing about programming language or implementation (often multiple implementations are possible for the same solution and implementations may differ between languages). These two clearly serve different purposes. However, can they both be achieved by using a wrapper class (thus same implementation, different purpose)? [See slide 50 for clarity.](http://www.slideshare.net/anujarosha/design-patterns-9388352) (I assume the answer is yes) – user8363 Mar 18 '15 at 15:57
  • Could you add this to your answer, so it more closely answers the actual question. Then I'll gladly accept it. – user8363 Mar 18 '15 at 16:55
  • I deleted my previous comment cos I think it's incorrect. Please check my new "Pattern vs. Goal" section in the answer. :) – Mouhong Lin Mar 18 '15 at 18:59
  • In this case I actually do care about the read-only interface pattern. I needed my class to be mutable by some select classes (the 'inner' classes of the module) and immutable to others (the classes exposed by the API). I applied the pattern and saw some similarities with the facade pattern, because I implemented the read-only interface pattern using a wrapper class (using Javascript, there are no interfaces). – user8363 Mar 18 '15 at 22:32
  • I'd say I've gotten confused by the wikipedia article (and in turn confused you) as it seems to talk about immutable interfaces but _not_ about the read-only interface pattern. – user8363 Mar 18 '15 at 22:34
  • Yea, the names are so similar :) – Mouhong Lin Mar 19 '15 at 00:39
  • The Difference is predicated on design intent exclusively. The Motivation behind the Facade Pattern should be interpreted in the context in which it was intended (To provide a simplified interface to a complex system of cooperative class hierarchy.) The fact that, the pattern also abstracts away a level of mutability in it's subjective components, is merely a consequence of the patterns motivation. – Abstraction is everything. Dec 11 '16 at 20:40