Head first design patterns

This book should be the most interesting one I have read so far. It contains many illustrations, humorous words, and often uses anthropomorphic methods, for example, the dialogue between the abstract factory and the factory method mode does not mean that the depth is not enough. On the contrary, he explained the problem very thoroughly.

This book is very different from the computer books I have read before. It is also based on Reading Notes or Blackboard-based teaching. actually, what I want to say is that when I read this book, I don't feel like I am reading a book, but I feel like I am sitting in the classroom to listen. really, if I have the opportunity to teach the design pattern course, this book is my first choice !! (I feel like I am selling the advertisement for this book ?? I have never received any tip for this book .)

If I use a simple sentence to express my feelings about reading this book, I would like to say, "I don't know when the mainland will release the photocopy of this book. I 'd like to buy it ". (people who cannot afford the original version said with tears .)

The following is my understanding of the design model and understanding of this book.

The design model is actually a product. What is the product? Is the product of solving a specific problem (context) using the OO principle. So what is the OO principle? Is the OO principle also a product? What is the product? It is to make it easier to expand the code and make the software easier to maintain in the future. You just sum up some experiences to make it easier to achieve this purpose.

As the saying goes: "It is easy to attack the city and it is difficult to guard the city !", It is easy to write a software program, but it is difficult to maintain the software for a long time to meet the requirements.

Let's look at the features of OO basic and some oo principles to see how the design pattern applies oo basic to implement some oo principle.

1.1. Oo basic

· Invalid action

· Inheritance

· Polymorphism

· Encapsulation

1.2. Oo Principle

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

· Program to an interface, not an implementation.

· Favor composition over inheritance.

· Strive for loosely coupled designs between objects that interact.

· Classes shoshould be open for extension but closed for modification.

· Depend on your action. Do not depend on concrete classes.

· Principle of least knowledge-talk only to your immediate friends.

· Don't call us, we will call you.

· A Class shoshould have one reason to change.

 

1.3. Design Patterns 1.3.1. Strategy Pattern

Defines a family of algorithms, encapsulates each one, and make them interchangeable. Strategy lets the algorithm vary independently from client that uses it.

1.3.2. Observer

Defines a one-to-define dependency between objects so that when object change state, all its dependents are notified and updated automatically.

1.3.3. Decorator

Attach additional responsibilities to an object dynamically. decorators provide a flexible alternative to subclassing for extending functionality.

1.3.4. Abstract Factory

Provide an interface for creating families of related or dependent objects without specifying their concrete classes.

1.3.5. Factory method

Define an interface for creating an object, but let subclass decide which class to instantiate. Factory method let a class defer Instantiation to the subclass.

1.3.6. Singleton

Ensure a class only has one instance and provide a global point of access to it.

1.3.7. Command

Encapsulates a request as an object, thereby leize you parameterize clients with different requests, queue or log requests, and support undoable operations.

1.3.8. Adapter

Converts the interface of a class into another interface the client expects. Adapter lets classes work together that couldn't otherwise because of incompatible interfaces.

1.3.9. Facade

Provides a uniied interface to a set of interfaces in a subsystem. fa çade defines a higher-level interface that makes the subsystem easier to use.

1.3.10. Template Method

Define the skeleton of an algorithm in an operation deferring some steps to subclasses. template method lets subclasses redefine certain steps of an algorithm without changing the algorithm's structure.

1.3.11. Iterator

Provide a way to access the elements of an aggregate object sequentially without exposing its underlying representation.

1.3.12. Composite

Compose objects into tree structures to represent part-whole hierarchies. Composite lets clients treat individual objects and composition of objects uniformly.

1.3.13. State

Allow an object to alter its behavior when its internal state changes. The object will appear to change its class.

1.3.14. Proxy

Provide a surrogate or placeholder for another object to control access to it.