The learning Note of Head First Design Pattern

Chapter 1. Intro to Design Patterns: Welcome to Design Patterns

NOTE：
HAS-A can be better than IS-A
The Strategy Pattern defined:

SUMMARY：

Chapter 2. The Observer Pattern: Keeping your Objects in the know

The Observer Pattern defined：


SUMMARY：

Chapter 3. The Decorator Pattern: Decorating Objects

The Decorator Pattern defined:

SUMMARY：

Chapter 4. The Factory Pattern: Baking with OO Goodness

The Dependency Inversion Principle：
It should be pretty clear that reducing dependencies to concrete classes in our code is a “good thing.” In fact, we’ve got an OO design principle that formalizes this notion; it even has a big, formal name: Dependency Inversion Principle.


NOTE：
A “high-level” component is a class with behavior defined in terms of other, “low-level” components.
For example, PizzaStore is a high-level component because its behavior is defined in terms of pizzas - it creates all the different pizza objects, and prepares, bakes, cuts, and boxes them, while the pizzas it uses are low-level components.
Where’s the “inversion” in Dependency Inversion Principle?
The “inversion” in the name Dependency Inversion Principle is there because it inverts the way you typically might think about your OO design. Look at the diagram on the previous page. Notice that the low-level components now depend on a higher level abstraction. Likewise, the high-level component is also tied to the same abstraction. So, the top-to-bottom dependency chart we drew a couple of pages back has inverted itself, with both high-level and low-level modules now depending on the abstraction.
Let’s also walk through the thinking behind the typical design process and see how introducing the principle can invert the way we think about the design…
A few guidelines to help you follow the Principle…
The following guidelines can help you avoid OO designs that violate the Dependency Inversion Principle:

• No variable should hold a reference to a concrete class.
  NOTE
  If you use new, you’ll be holding a reference to a concrete class. Use a factory to get around that!
• No class should derive from a concrete class.
  NOTE
  If you derive from a concrete class, you’re depending on a concrete class. Derive from an abstraction, like an interface or an abstract class.
• No method should override an implemented method of any of its base classes.
  NOTE
  If you override an implemented method, then your base class wasn’t really an abstraction to start with. Those methods implemented in the base class are meant to be shared by all your subclasses.
  The Factory Method Pattern defined:
  
  
  
  
  Abstract Factory Pattern defined:
  
  
  Factory Method and Abstract Factory compared:
  
  
  SUMMARY:
  Tools for your Design Toolbox
  In this chapter, we added two more tools to your toolbox: Factory Method and Abstract Factory. Both patterns encapsulate object creation and allow you to decouple your code from concrete types.
  
  • All factories encapsulate object creation.
  • Simple Factory, while not a bona fide design pattern, is a simple way to decouple your clients from concrete classes.
  • Factory Method relies on inheritance: object creation is delegated to subclasses, which implement the factory method to create objects.
  • Abstract Factory relies on object composition: object creation is implemented in methods exposed in the factory interface.
  • All factory patterns promote loose coupling by reducing the dependency of your application on concrete classes.
  • The intent of Factory Method is to allow a class to defer instantiation to its subclasses.
  • The intent of Abstract Factory is to create families of related objects without having to depend on their concrete classes.
  • The Dependency Inversion Principle guides us to avoid dependencies on concrete types and to strive for abstractions.
  • Factories are a powerful technique for coding to abstractions, not concrete classes.