meeting -*- Outline -*-

* Designing Use Case Realizations with Gang of Four Design Patterns (Ch. 23)

  Copy figure 23.1

  See also the design patterns book.

  We're going to explore this in terms of a case study which tackle
  support for external third-party services is interfaces may vary,
  complex pricing rules, and pluggable business rules.

  The idea is to get across the principles and idioms of object
  design.

  This chapter only does some of the gang of four patterns.

** adapter (23.1)
   See also the design patterns book, pages 139 and following 
------------------------------------------
              ADAPTER (23.1)

Problem:
 How to resolve incompatible interfaces?
 How to provide stable interface
 to similar components
 with different interfaces?

Solution:
 An intermediate object that translates
 calls from one interface to the other.

Example:

------------------------------------------
        tax calculator adapter interface with getTaxes(Reservation)
        method

        Accounting system adapter
                   postReceivable(CreditPayment)
                   postSale(Reservation)

        Show figure 23.1

        in C++ use an abstract class.

------------------------------------------
          C++ HEADER FILES

// $RCSfile: AccountingAdapter.h,v $
#ifndef AccountingAdapter_h
#define AccountingAdapter_h

#include "CreditPayment.h"
#include "Reservation.h"

class AccountingAdapter {
public:
   virtual void
   postReceivable(CreditPayment *p);

   virtual void postSale(Reservation *r);
};

#endif


// $RCSfile: SAPAccountingAdapter.h,v $
#ifndef SAPAccountingAdapter_h
#define SAPAccountingAdapter_h

#include "AccountingAdapter.h"
#include "SAPAccounting.h"

class SAPAccountingAdapter
             : public AccountingAdapter {
public:
  virtual void
  postReceivable(CreditPayment *p);

  virtual void postSale(Reservation *r);

private:
  SAPAccounting *accounts;
};

#endif
------------------------------------------

------------------------------------------
           // C++ CODE FILES

// $RCSfile: AccountingAdapter.cpp,v $
#include "AccountingAdapter.h"


// $RCSfile: SAPAccountingAdapter.cpp,v $
#include "SAPAccountingAdapter.h"
void SAPAccountingAdapter::
     postReceivable(CreditPayment *p) {
  accounts->receive(p->pennies(),
                    p->description());
}

void SAPAccountingAdapter::
     postSale(Reservation *r) {
  accounts->sell(r->pennies(),
                 r->description());
}

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

        Other examples from the design patterns book,
        text shape adapter, subclass of shape

                   Shape
                 BoundingBox()
                 CreateManipulator()
                    ^
          __________|__________
          |                   |
         Line                TextShape
      BoundingBox()        BoundingBox()
      CreateManipulator()  CreateManipulator()

*** Discussion
   support protected variations
   interface is an Indirection

   put pattern name in type name

*** related patterns
    - Facade, a resource adapter that hides an external system is a Facade
      the difference is that an adapter also translates the protocol

*** analysis discoveries during design (23.2)

    Larman observes that during design he discovers the need for a
    TaxLineItems concept/class that is the return type of the getTaxes
    method.

    "It is normal in common to discover noteworthy domain
    concepts... during design or programming"

    One can update the domain model to reflect this,
    however one has to consider whether the domain model is worth
    maintaining.

    an alternative is to reverse engineer the class diagrams and to
    use the domain layer of the design model instead of the true
    domain model.