1

I'm studying design patterns to improve my programming skills. Right now, I'm exploring the facade design pattern.

I may be confusing myself, but, as an example: isn't the Scanner is a facade? Note that I'm not asking what is a Facade, but trying to identify if Scanner is.

Well, I declare it so I can use certain features without contacting complex and deeper functions, right?

I declare

Scanner sc = new Scanner(System.in);

so I can:

String x = sc.nextLine();
Lodi
  • 565
  • 4
  • 16
  • Possible duplicate of [What is the facade design pattern?](https://stackoverflow.com/questions/5242429/what-is-the-facade-design-pattern). – Jonny Henly Apr 10 '19 at 17:53
  • Not really. `Scanner` provides functionality that `InputStream` doesn't, so it's not really a Facade. – Matt Timmermans Apr 10 '19 at 19:56

2 Answers2

2

This is a good example of class which simplifies an API and makes it clear and closer to what is used for. When we want to read data from user in console app InputStream would be hard to use. Let's take a look on some definition of Facade pattern and match with Scanner class:

Intent

  • Provide a unified interface to a set of interfaces in a subsystem. Facade defines a higher-level interface that makes the subsystem easier to use.
  • Wrap a complicated subsystem with a simpler interface.

Scanner class matches both above points.

Check list

  1. Identify a simpler, unified interface for the subsystem or component.
  2. Design a 'wrapper' class that encapsulates the subsystem.
  3. The facade/wrapper captures the complexity and collaborations of the component, and delegates to the appropriate methods.
  4. The client uses (is coupled to) the Facade only.
  5. Consider whether additional Facades would add value.

Scanner class matches all above points. So, we can consider Scanner as a facade for InputStream.

Mark Rotteveel
  • 100,966
  • 191
  • 140
  • 197
Michał Ziober
  • 37,175
  • 18
  • 99
  • 146
  • 1
    Perfect! Thank you. I think I'm going on the right path – Lodi Apr 10 '19 at 20:33
  • `Scanner` does not unify any set of interfaces, nor does it simplify the `Readable` interface it wraps. The `Scanner` API is far more complex than `Readable`. – jaco0646 Apr 10 '19 at 22:26
  • @jaco0646, `Facade` can simplify `API` for one `interface` as well. Of course, it is much clear to see it when we have more than one but one is enough. Maybe it has much complex `API` than `Readable` but it makes it easier to use when we read data from console. `parseInt`, `nextLine`, `hasNextLine` as much simpler to understand and use than `read` next bytes. Also, we can create other `Facade` over `Scanner` which simplifies console usage for our requirements. For example, in case we need to read only a few numbers from console we can limit `Scanner` `API` to required methods only. – Michał Ziober Apr 11 '19 at 06:13
1

Facade consolidates a one-to-many relationship into a one-to-one relationship for its clients. They become simpler because they depend on one (high-level) Facade rather than many (low-level) individual components. The Facade itself takes over the many low-level dependencies (and delegates to them).

The relationship of Scanner to its Readable source is plain old object composition. There is no consolidation of dependencies. While it's true that Scanner provides new functionality and is a higher-level abstraction than Readable, that is true of many or most composition relationships.

A Facade both reduces dependencies (coupling) and increases abstraction for its clients. Notice that diagrams of the Facade Pattern always show multiple outgoing arrows from the Facade object.

jaco0646
  • 15,303
  • 7
  • 59
  • 83