Best Quotes from Head First Design Patterns by Ericfreeman with Page Numbers

Someone has already solved your problems.

Instead of code reuse, with patterns you get experience reuse.

The best way to use patterns is to load your brain with them.

You could spend less time reworking code and more making the program do cooler things.

The one constant in software development is CHANGE.

Design patterns provide a way to let some part of a system vary independently of all other parts.

Identify the aspects of your application that vary and separate them from what stays the same.

Favor composition over inheritance.

The Strategy Pattern defines a family of algorithms, encapsulates each one, and makes them interchangeable.

When you communicate using patterns, you are doing more than just sharing LINGO.

You don’t want to miss out when something interesting happens, do you?

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

Strive for loosely coupled designs between objects that interact.

A newspaper subscription, with its publisher and subscribers, is a good way to visualize the pattern.

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

Identify the aspects of your application that vary and separate them from what stays the same.

Favor composition over inheritance.

Program to an interface, not an implementation.

You can push or pull data from the Subject when using the pattern (pull is considered more 'correct').

The Observer Pattern is a commonly used pattern, and we’ll see it again when we learn about Model-View-Controller.

"I used to think real men subclassed everything. That was until I learned the power of extension at runtime, rather than at compile time."

"Classes should be open for extension, but closed for modification."

"Our goal is to allow classes to be easily extended to incorporate new behavior without modifying existing code."

"Decorators provide a flexible alternative to subclassing for extending functionality."

"By dynamically composing objects, I can add new functionality by writing new code rather than altering existing code."

"When we got this code, Starbuzz already had an abstract Beverage class. Traditionally, the Decorator Pattern does specify an abstract component, but in Java, obviously, we could use an interface."

"Decorators change the behavior of their components by adding new functionality before and/or after (or even in place of) method calls to the component."

"Inheritance is one form of extension, but not necessarily the best way to achieve flexibility in our designs."

"We can implement new decorators at any time to add new behavior. If we relied on inheritance, we’d have to go in and change existing code anytime we wanted new behavior."

"Remember, code should be closed (to change) like the lotus flower in the evening, yet open (to extension) like the lotus flower in the morning."

"Get ready to bake some loosely coupled OO designs."

"When you see 'new,' think 'concrete.'"

"Remember that designs should be 'open for extension but closed for modification.'"

"By coding to an interface, you know you can insulate yourself from many of the changes that might happen to a system down the road."

"Identifying the aspects that vary lets you separate them from what stays the same."

"Factory Patterns can help save you from embarrassing dependencies."

"The real culprit is our old friend CHANGE and how change impacts our use of new."

"Factory Method Pattern defines an interface for creating an object, but lets subclasses decide which class to instantiate."

"Cheap and cheesy pizzas might be selling today, but in the long run, quality ingredients will keep your customers coming back."

"Depend upon abstractions. Do not depend upon concrete classes."

"The Singleton Pattern ensures a class has only one instance, and provides a global point of access to it."

"In many ways, the Singleton Pattern is a convention for ensuring one and only one object is instantiated for a given class."

"There is power in ONE."

"By using an object like me you can ensure that every object in your application is making use of the same global resource."

"The truth be told…well, this is getting kind of personal but…I have no public constructor."

"When you need to ensure you only have one instance of a class running around your application, turn to the Singleton."

"Beware of the double-checked locking implementation; it isn’t thread safe in versions before Java 5."

"Singletons are meant to be used sparingly."

"It’s a common criticism of the Singleton Pattern that it can create tight coupling between components."

"You might be happy to know that of all patterns, the Singleton is the simplest in terms of its class diagram."

by encapsulating method invocation, we can crystallize pieces of computation so that the object invoking the computation doesn’t need to worry about how to do things.

The Command Pattern allows you to decouple the requester of an action from the object that actually performs the action.

The remote should know how to interpret button presses and make requests, but it shouldn’t know a lot about home automation or how to turn on a hot tub.

Using this pattern, we could create an API in which these command objects can be loaded into button slots, allowing the remote code to stay very simple.

A command object encapsulates a request to do something (like turn on a light) on a specific object (say, the living room light object).

An encapsulated request lets you parameterize other objects with different requests, queue or log requests, and support undoable operations.

The Command Pattern decouples an object making a request from the one that knows how to perform it.

A Macro Command is a simple extension of the Command Pattern that allows multiple commands to be invoked.

The Command Pattern can support the semantics of logging all actions and being able to recover after a crash by reinvoking those actions.

Whenever a button is pressed, we take the command and first execute it; then we save a reference to it in the undoCommand instance variable.

That's the beauty of our profession: we can make things look like something they’re not!

A decoupled client is a happy client.

The Adapter Pattern converts the interface of a class into another interface the clients expect.

A Facade is just what you need: with the Facade Pattern, you can take a complex subsystem and make it easier to use.

The Principle of Least Knowledge guides us to reduce the interactions between objects to just a few close "friends."

Encapsulate what varies.

Talk only to your immediate friends.

An adapter changes an interface into one a client expects.

A facade decouples a client from a complex subsystem.

The Facade Pattern provides a unified interface to a set of interfaces in a subsystem.

The Template Method Pattern defines the skeleton of an algorithm in a method, deferring some steps to subclasses.

Don’t call us, we’ll call you.

The Hollywood Principle gives us a way to prevent 'dependency rot'.

Template Method lets subclasses redefine certain steps of an algorithm without changing the algorithm’s structure.

The CaffeineBeverage class runs the show; it has the algorithm, and protects it.

Every part of my algorithm is the same except for, say, one line, then my classes are much more efficient.

This pattern shows up so often because it’s a great design tool for creating frameworks.

With Template Method, you can reuse code like a pro while keeping control of your algorithms.

You’ll see lots of uses of the Template Method Pattern in real-world code, but don’t expect it all to be designed 'by the book'.

Abstract methods are implemented by subclasses.

"If we’ve learned one thing in this book, it’s to encapsulate what varies."

"Encapsulating iteration is not just a clever trick; it’s a fundamental design pattern."

"The Iterator Pattern allows you to access the elements of an aggregate object sequentially without exposing its underlying representation."

"The Composite Pattern allows you to compose objects into tree structures to represent part-whole hierarchies."

"Every responsibility of a class is an area of potential change. More than one responsibility means more than one area of change."

"You can add a menu item or another menu with confidence, knowing the rest of the system won’t have to change."

"The implementation isn’t based on MXML (Menu XML) and so isn’t as interoperable as it should be."

"A class should have only one reason to change."

"By giving her an Iterator, we have decoupled her from the implementation of the menu items, so we can easily add new Menus if we want."

"The waitresses have become much happier. They no longer need to worry about which type of menu they are dealing with."

The State Pattern allows an object to alter its behavior when its internal state changes.

The object will appear to change its class.

Each state is responsible for its own behavior.

Encapsulating state into separate classes reduces the complexity of conditional statements.

By using composition, we can change the state of an object dynamically.

Each ConcreteState provides its own implementation for a request.

The State Pattern is a powerful way to manage state-based behavior.

The flexibility of the State Pattern often results in a clearer and more maintainable design.

Understanding the State and Strategy patterns helps clarify the relationship between behavior and states.

The Gumball Machine now holds an instance of each State class, providing clarity and reducing complexity.

The Proxy Pattern provides a surrogate or placeholder for another object to control access to it.

A Proxy acts as a representative for another object.

Use the Proxy Pattern to create a representative object that controls access to another object, which may be remote, expensive to create, or in need of securing.

Proxies have been known to haul entire method calls over the internet for their proxied objects.

In the case of the gumball machine, just think of the proxy controlling access so that it could handle the network details for us.

The Proxy Pattern allows a client to interact with a remote object as if it were a local object.

We’re going to write some code that takes a method invocation, somehow transfers it over the network, and invokes the same method on a remote object.

A remote proxy acts as a local representative to a remote object.

The proxy controls access to the RealSubject, which is the object that does the real work.

The Decorator Pattern adds behavior to an object, while Proxy controls access.

One of the best ways to use patterns is to get them out of the house so they can interact with other patterns.

A compound pattern combines two or more patterns into a solution that solves a recurring or general problem.

The more you use patterns the more you’re going to see them showing up together in your designs.

Well, believe it or not, some of the most powerful OO designs use several patterns together.

You only want to apply patterns when and where they make sense.

Patterns are often used together and combined within the same design solution.

Sometimes just using good OO design principles can solve a problem well enough on its own.

The beauty of Design Patterns is that I can take a problem and start applying patterns to it until I have a solution.

What we did was a set of patterns working together.

The real secret to learning MVC: it’s just a few patterns put together.

A Pattern is a solution to a problem in a context.

If you find yourself in a context with a problem that has a goal that is affected by a set of constraints, then you can apply a design that resolves the goal and constraints and leads to a solution.

There is one situation in which you’ll want to use a pattern even if a simpler solution would work: when you expect aspects of your system to vary.

Design Patterns aren’t a magic bullet; in fact, they’re not even a bullet!

Let patterns emerge naturally as your design progresses.

Go for simplicity and don’t become overexcited.

Always start from your principles and create the simplest code you can that does the job.

Patterns are tools, not rules—they need to be tweaked and adapted to your problem.

Don't let us discourage you, though. When a Design Pattern is the right tool for the job, the advantages are many.

Remember, most patterns you encounter will be adaptations of existing patterns, not new patterns.

But these patterns are awesome in their own right, and if your situation calls for them, you should apply them with your head held high.

The Bridge Pattern allows you to vary the implementation and the abstraction by placing the two in separate class hierarchies.

Encapsulates the way a complex object is constructed.

The Client directs the builder to construct the planner.

Decouples the sender of the request and its receivers.

Execution of the request isn’t guaranteed; it may fall off the end of the chain if no object handles it.

Reduces the number of object instances at runtime, saving memory.

The Memento has two goals: saving the important state of a system’s key object and maintaining the key object’s encapsulation.

The Prototype Pattern allows you to make new instances by copying existing instances.

The Visitor allows you to add operations to a Composite structure without changing the structure itself.