Richard Monson-haefel, a well-known top expert in the EJB field, strongly recommends gof's design pattern on its personal website www.ejbnow.com. The original Article is as follows:
Design Patterns
Most developers claim to experience an epiphany reading this book. If you 've never read the design patterns book then you have suffered a very serious gap in your programming education that shocould be remedied immediately.
After reading this book, many programmers announce that they have gone through the "Main Festival" (the dual festival to commemorate the birth and baptism of the father). If you have never read this book, you will have a serious split in your program education career, so you should immediately make up for it!
It can be said that: The gof design mode is a required course for programmers to truly grasp the core idea of object-oriented. Although you may have already passed many dazzling technical certifications from sun, if you have not learned how to master the gof design model, it only means that you are still a technician.
When browsing thingking in Java (the first version), do you think this is still a basic Java language book? But it is not purely because the author of this book cleverly integrates the object-oriented thinking into the specific Java technology, it makes you feel the birth of a new language and a new way of thinking.
However, after reading this book, you may need a clearer, more systematic, and more thorough understanding of these ideas in the book, so you need to study gof's design patterns.
Thingking in Java (the first Chinese Version) describes the design pattern in this way: by gamma, Helm, and Johnson vlissides (Gang of Four ), the design patterns, compiled by gof, is defined as a "Milestone ". In fact, this book has now become a reference book essential to almost all OOP (Object-Oriented Programming) programmers. (In foreign countries ).
Gof's design pattern is the basis of all object-oriented languages (C ++ Java C #), but different languages implement it more conveniently.
The gof design model is a "bridge"
As far as the Java language system is concerned, the gof design mode is an implicit "bridge" between Java basic knowledge and J2EE framework knowledge ".
There are more and more developers who are familiar with Java, but there are not a few programmers who have been wandering at the language level. There are not many applications that really grasp interfaces or abstract classes in Java. We often say that those technologies are only suitable for large projects, avoid or ignore them. In reality, Java interfaces or abstract classes are the core of the true embodiment of Java ideas, and you will see their changing magic in the gof design patterns.
On the surface, the gof design pattern seems to be a specific "technology", and new design patterns are constantly emerging. The design pattern has its own development track, which seems to be similar to J2EE. net and other technologies have nothing to do!
In fact, the gof design pattern is not a specific "technology", it tells the idea, it not only shows the flexible application and wisdom of interfaces or abstract classes in actual cases, so that you can really grasp the application of interfaces or abstract classes, so as to step forward on the basis of the original Java language. More importantly, the gof design pattern repeatedly emphasizes a purpose for you: make your program as reusable as possible.
This is actually a challenge to the extreme: the demand for software is changing infinitely, and the plan is not changing fast, but we still need to find something that remains unchanged and separate it from what is changing, this requires great wisdom and experience.
The gof design model is a milestone that begins to be explored in this respect.
J2EE is a framework software. What is Framework software? It is different from the Java APIs we used previously, which belong to toolkist (Toolkit). It is no longer passively used or called, but deeply involved in a field, the purpose of the framework software design such as J2EE is to first define the unchanged things in a field, such as the overall structure and some main responsibilities (such as database operation Transaction Tracking security ), the rest is the changing things. The specific changing requirements for specific applications in this field are what J2EE programmers need to do.
It can be seen that the design mode and J2EE are in the same ideological and motivation,
1. The design pattern is more abstract. J2EE is the specific product code, which we can access. The design pattern generates the specific code for each application.
2. the design pattern is a smaller architecture than the framework software such as J2EE. Many specific programs in J2EE are completed by the application design pattern. When you go deep into the internal code Research of J2EE, this is especially obvious. Therefore, if you do not have the basic knowledge of design patterns (gof's design patterns), it is difficult for you to quickly understand J2EE. I cannot understand J2EE. How can I use it flexibly?
3. J2EE is only a framework Software suitable for enterprise computing applications, but the gof design mode can be used for almost any application! Therefore, the gof design mode should be one of the important theoretical foundations of J2EE.
Therefore, the gof design mode is an implicit "bridge" between Java basic knowledge and J2EE framework knowledge ". Why is it implicit?
Gof's design model is a hidden "bridge"
Many people did not notice this. After learning the Basic Java language, they went to learn J2EE directly. Some even ran away and used Weblogic and other specific J2EE software directly. After a while, they found that, it's easy to use, but do you really understand J2EE? Is your application in specific cases also extending the idea of J2EE?
If you can't extend the idea of J2EE well, wouldn't you be a blockbuster? It's wise to realize that J2EE is not suitable for everyone, at least, however, we need to use J2EE in a proper place. Only by understanding the essence of J2EE framework software can you use Java flexibly to solve your problem, you can even build your own enterprise framework. (We cannot always use frameworks set by others. Why cannot we have our own frameworks ?)
Therefore, you must first master the gof design model. Although it is implicit, it cannot be crossed.
About the "design mode" of this site"
Java provides a wide range of APIs and a powerful database system for underlying support, so our programming seems to have become a simple "Patchwork" and call similar to building blocks, some people even advocate "blue-collar programmers", which are not familiar with modern programming technologies.
In truly reusable object-oriented programming, gof's Design Pattern provides us with a set of reusable Object-oriented technologies, coupled with refactoring ), therefore, there are few simple repetitive tasks, and Java code refinement and object-oriented purity (the design pattern is the soul of Java ), programming becomes an exciting process that allows you to experience creative pleasure at all times.
In order to be able to discuss "design patterns" with everyone, I wrote down my experiences in learning, just to help more people better understand gof's "design patterns". Since the original works are based on C ++ as an example, the design patterns of Java are basically based on graphics applications, and we are more concerned with Java's applications on middleware and other servers, all instances on this site are non-graphic applications, and the jive forum system is analyzed along with them. at the same time, to reduce the understanding difficulty, avoid using UML diagrams.
If you have some experience in Object-Oriented Programming, you will find that you have used some of the design patterns unconsciously. If you are a newbie, from the very beginning, cultivate your own good programming habits (to make your program use a common pattern for others' understanding; To reduce repetitive programming work ), this is undoubtedly a prerequisite for becoming a good programmer.
The entire design pattern runs through one principle: interface programming rather than implementation. The objective principle is to reduce coupling and enhance flexibility.