Facade pattern or just expose child objects?

Question

Wondering about pros and cons around a facade pattern implementation (or perhaps there is a better pattern I should consider), versus simply exposing a dependent object to a caller.

Consider the following:

public class Model implements Player  {
  private Player player;

  /*
     implement Player interface, which simply delegates calls to my player object
  */
  @Override
  public void play() {
    player.play();
  }
}

vs

public class Model {
  private Player player;

  public Player getPlayer() {
    return player;
  }
}

Similarly to another question on here around Facade patterns (Beginner Facade Pattern Example), I'm worried that my Model class will just keep extending interface after interface which is terrible DRY without gaining much. However, my model class here is the model object for an MVC pattern. I would like my controller to only talk to my model, and not worry about child objects held by the model. When the controller wants my app to play(), calling model.play() seems better than model.player.play().

As my model becomes more complex, what is the best way to manage these conflicting paradigms?

What are you trying to accomplish in using the Facade pattern? Without knowing the goal, there are dozens of answers that can be given. Your question asks about a specific implementation, but specific implementations tend to depend on the specific goals of the specific project desired by a specific designer. — Dunk, Mar 28 '17 at 19:05
I was worried about tight coupling between my Player and the caller. — gdbj, Mar 28 '17 at 19:50

score 2 · Accepted Answer · answered Mar 28 '17 at 01:21

2

The "Law" of Demeter says to use the Facade / Wrapper. DRY (and programmer laziness) says just expose the child. Usually lazy == good.

IMO, if the child object (Player in your example) is well known, stable and (ideally) somewhat abstract, such as a List or Stream, with no special cases or gotchas, just expose it.

If it is complicated and the user has a good chance of messing it up (say it has synchronization or internal-validity issues) then protect it.

answered Mar 28 '17 at 01:21

user949300

8,679
2
26
35

This is the kind of logic that I couldn't walk myself through. – gdbj Mar 28 '17 at 19:46
Oh boy....expose a List...that's another topic...it is probably not a good idea in most cases, unless that list is read-only. – Dunk Mar 28 '17 at 23:01
@Dunk Valid point. Either wrap it in an Immutable list, or, in the comments, state whether clients should modify it never, always, or only with great care. A final option to consider is to return an `Iterable` or `Enumeration`, but those often have problems too. – user949300 Mar 28 '17 at 23:39

score 1 · Answer 2 · answered Mar 27 '17 at 18:49

1

Why did you think of using the Facade Pattern in the first place?

From Wikipedia:

A Facade is used when an easier or simpler interface to an underlying object is desired.

Facade adds no value if you're not simplifying the interface but just delegating method by method.

answered Mar 27 '17 at 18:49

Apalala

2,283
13
19

It is a facade, since it hides Player to the caller, thereby simplifying the interface. The example above is trivial, but it could be made more interesting. Also, other objects will be created as we build the project out, so I'm trying to understand how best to architect it now. Do I make all the callers dependent on knowing the Player object? Or do I hide it? – gdbj Mar 27 '17 at 20:57
Delegating the entire interface to start out sounds like more work out of the gate, so I think you're right. If no obvious simplification in the interface exists, probably best to just take the easy route and expose Player to the caller. – gdbj Mar 27 '17 at 21:03
-1 Not an answer – Maybe_Factor Mar 28 '17 at 01:26
1

@gdbj: This is a *decorator*, not a *facade*. A *facade* does not implement the same interface as the objects it delegates to. – marstato Mar 28 '17 at 08:10

score 1 · Answer 3 · answered Mar 27 '17 at 22:28

Cons: A facade requires more typing.

Pros: A facade can make things much simpler for the caller, and can also serve to prevent them from perform illegal actions.

Your example is pretty trivial, but imagine a more complicated interface. Perhaps if the input to player.Move(positionData) isn't just a simple coordinate but requires custom location info, e.g. a path into a binary space partition. Maybe you don't want the caller to have to figure that out, so you provide a facade method that accepts Cartesian coordinates. The facade may call a second class to compute the BSP path from the coordinates, and then issue the call to player.Move(). In that sort of setup, the facade could provide a lot of usability to the caller, as well as ensuring that the path is valid.

I'm building a GUI around an ML application, and we're at version 0. I'm trying to anticipate future complexity as you describe. Right now, I'm basically duplicating my Player interface on my Model, and hiding Player. But, perhaps exposing my Player to the caller is simply part of the model's interface. I tend to agonize over these kinds of decisions so I ask on SO, and someone tells me to KISS. — gdbj, Mar 28 '17 at 19:46
Don't expose the Player interface. That's KISS and reduces risk dramatically. — Dunk, Mar 28 '17 at 22:57

score 0 · Answer 4 · answered Mar 28 '17 at 01:05

The Facade pattern is generally for representing a complex sub-system in a simpler way to calling code that doesn't need to know all the details about it. For example, you may have a component that exposes dozens of methods, but you only want the UI to know about 3 of them. Perhaps the methods on your component are primitive, and the UI needs to call combinations of them at different times. In this kind of case you may want to use the Facade pattern, but it sounds like you want something different.

What are you trying to achieve by implementing a pattern here? If you are just trying to loosen the coupling between your UI and model, then simply using an interface is enough. I wouldn't call this the Facade pattern though, it's just basic OOP.

Also keep in mind that when it comes to design pattern, appropriate use is very much guided by the project size, complexity, or other requirements. If there is anything else you can tell us about the scope of the project, it could be very helpful for giving more detailed advice.

Dunk · Answer 5 · 2017-03-28T22:55:14.957

Based on the response "I was worried about tight coupling between my Player and the caller."

The Facade Pattern doesn't have any hidden agenda. It is a very straight forward pattern. Make your application classes easier to use for the "user" code.

The Facade Pattern is not intended to reduce coupling from individual classes. Reduced coupling of the "Facaded" code is generally a by-product of doing that.

To give a concrete example, suppose I wanted to command my system to start collecting data and report events as they occur. In order to turn the system on, it might need to register the control interface to receive specific events, turn a sensor or two on, read the GPS data, read weather information, position the sensors, provide readings to algorithm processing modules etc...each of those will have at least one class representing it. While the application developer may know how to put all those pieces together, the poor developer developing the user-interface is going to have their hands full figuring it all out.

IOW, that's a lot for "user" code to know when all they really want to do is say StartDataCollection(). Thus, the Facade is born. All that knowledge of coordinating the classes to coordinate the processing is hidden behind that Facade.

If all your system is going to ever have is 1 "user" code implementation or the same developer is implementing the application and "user" interface then Facade is probably not needed and maybe some sort of Command Pattern or operation concept is an option.

Where the Facade shines is when your system has multiple "user" interface types that can control it. By using the Facade, with the addition of events, asynchronous processing, message queues, perhaps some application specific rules, etc... and ensuring that the Facade and your application code is user interface agnostic, the job of implementing new types of interfaces only ends up becoming one of writing/reading data to/from the physical interface. Getting the app to do the right things is trivial because you simply make calls on the Facade and receive events from the Facade.

Also, you can develop and test the "user" interface totally stand-alone from your application. While that is good in its own right, it is a silver bullet for meeting deadlines because now you can throw more people at the problem (which almost never works in software development) as they can develop their software independently from others and user/control interfaces tend to not be as difficult as the main application processing.

Getting back to your question....Should Player be exposed or not? I'd say if all your Facade methods are simply regurgitating the corresponding method on the class then I think you need to revisit your use-cases or your design. I know you just gave a simple example, but basically what you've shown is that "Player" is really the Facade. The other option is that maybe the functionality within Player.Play() belongs in the Facade instead of Player.

I think it is OK to expose a limited set of classes in the Facade for simplicity, in particular with regards to reporting information. However, I would avoid exposing classes with the intent of initiating application operations. Create a Facade method for that. What happens if you change your application to allow multiple users but only 1 can Play at a time? If the "user" code has access to the Player instance then you're in for a bit of pain. If they only have access to the Facade Play() method then change number of users till your heart is content.

Facade pattern or just expose child objects?

5 Answers5