Here you can find my notes about each chapter in Head First Design Pattern Book

you can download the book from here

Chapter One “Welcome to Design Patterns”

as a software engineer you need to think about how to create flexible designs that are maintainable and that can cope the changes.

we’ve all used off the shelf libraries and frameworks. we take them, write some code against theirs APIs, compile them into our programs, and benefit from a lot of code someone else has written. but the don’t help us structure our own applications in ways that are easier to understand, more maintainable and flexible. that’s where design patterns come in.

Design patterns don’t go directly into your code, they first go into your BRAIN.

Capture

There are no DUMB questions !

  • If design patterns are so great why can’t someone build a library of them so i don’t have to
    • Design patterns are higher level than libraries. Design patterns tell us how to structure classes and objects to solve certain problems and it is our job to adapt those designs to fit our particular applications.
  • Aren’t libraries and frameworks also design patterns ?
    • Frameworks and libraries are not design patterns; they provide specific implementations that we link into our   code. sometimes, however libraries and frameworks make use of design patterns in their implementation.
  • so, there are no libraries of design patterns ? 
    • No, but you can learn about pattern catalogs with list of patterns that you can apply to your applications.

there are some object oriented principles that underlie that patterns, and knowing these will help you to cope      when you can’t find a pattern that matches your problem.

Tools for your Design toolbox

  1. OO Basics 
    • Abstraction
    • Encapsulation
    • Polymorphism
    • Inheritance
  2. OO Principles
    • Encapsulate what varies.
    • Favor composition over inheritance.
    • Program to interface, not implementations.
  3. OO Patterns
    • strategy- defines a family of algorithms encapsulates each one, and make the interchangeable. strategy lets the algorithms vary independently from clients that use it.

1

2

 

12

Chapter Two “Observer Pattern” – “Knowing your object in the known”

we’ve got a pattern that keeps your objects in the know when something they might care about happens.

Objects can even decide at runtime whether they want to be kept informed. the observer pattern is one of the most heavily used patterns in the JDK, and it’s incredibly useful.

You know how newspaper or magazine subscriptions work:

  1. A newspaper publisher goes into business and begins publishing newspapers.
  2. You subscribe to a particular publisher, and every time there’s a new edition it gets delivered to you. As long as you remain a subscriber, you get new newspapers.
  3. You unsubscribe when you don’t want papers anymore, and the stop being delivered.
  4. While the publisher remains in business, people, hotels, airlines and other businesses constantly subscribe and unsubscribe to the newspaper.

Publishers + Subscribers = Observer Pattern

If you understand newspaper subscriptions, you pretty much understand the Observer Pattern, only we call the publisher the SUBJECT and the subscribers the OBSERVERS.

Let’s take a closer look.Capture

The Observer Pattern: defines a one-to-many dependency between objects so that when one object changes state, all of its dependents are notified and updated automatically.

what does this have to do with one-to-many relationships ?

with the observer pattern, the subject is the object that contains the state and controls it. so there is one subject with state. the observers, on the other hand, use the state, even if they don’t own it. they are many observers and they rely on the subject to tell them rely on the subject to tell them when its state changes. so there is a relationship between the ONE subject to the MANY observers.

How does the dependence come into this ?

Because the subject is the sole owner of the data, the observers are dependent on the subject to update them to a cleaner OO design than allowing many objects to control the same data.

Design Principle

Strive for loosely coupled designs between objects that interacts. 

loosely coupled designs allow us to build flexible OO systems that can handle change because they minimize the interdependence between objects .