meeting -*- Outline -*-

** Facade (23.8)

   Another thing we want to do in this iteration is to support
   pluggable business rules.

   The idea is to support different business rules for different
   airlines who use the reservation system.

   For example:
   - children under 10 have to fly directly, and can't have a layover
   - airline company personnel aren't allowed to use their discount
     the day before Thanksgiving
   - connections to international flights require two hours to clear customs
   etc.

   We want to design that supports these kinds of complex rules,
   but factor out the rule handling into a separate concern (subsystem).
   We might even want to buy or use some open source components...

   Q: why can't we just use the strategy pattern?
      because were not just talking no one algorithm,
      but a whole complex set of data structures and algorithms.

------------------------------------------
        FACADE (23.8)

Problem:
  How to minimize coupling
  between subsystems?

  How to provide a higher-level interface
  that makes a subsystem easier to use?

  How to provide a simple default view
  of a subsystem?

Solution:
  Define a single object, the facade,
  that has responsibility for interacting
  with the rest of the system.

------------------------------------------

      a facade is an object that "front's" for a system.

      A compiler class the details of scanning, parsing,
      and abstract syntax trees and just allows clients to
      compile files.

      Q: is a handler a kind of facade object?
         yes

------------------------------------------
            EXAMPLE

public class Compiler {
  public Compiler() { ... }
  void compile (StringBuffer prog) {
    /* ... do all the work... */
  }
}
------------------------------------------

*** discussion
    Q: how many copies of the facade object do we need?
       usually only one, so we can use the singleton pattern to create
       it

    Q: do you really have to hide th other classes behind the facade?
       No.  How would we do that if we wanted  to?
               using non-public classes in Java, namespaces in C++, etc.

       a good time to explain the package notation in the UML, which
       is a tabbed folder icon

    Q: what's the impact of this pattern on coupling?

    Q: in a design that uses patterns, we tend to have lots of small
    classes.  How does this affect clients?

*** related patterns
    usually accessed by the singleton pattern
    provide protective variations from the implementation of a subsystem
    the facade class itself is a indirection

    Q: what's the difference between adapter and this pattern?