China
DW China all content ............... DW China Technology Zone: Component Technology Java Technology Linux XML ............... DW China Special Topics: Safety Unicode Site Architecture ............... IBM full content search help IBM Home | Products & Services | Support & Download | Personalized Services
IBM: DeveloperWorks China website: Java: All articles
Use design pattern to improve program structure (1)
content:
Introduction Problem Description Analysis Preliminary Plan Further Analysis Design Mode Floating Water Conclusion Reference About Authors
Also in The Java Zone:
Teaching tools and product code and components all articles practical skills
Sun Ming (Dhui@263.net)
software engineer
The design pattern is a solution that solves its elegant solutions after a specific issue has been summarized after countless experience. However, if you want to truly make the design pattern maximize, just know what the design pattern is, and how it is achieved, because you can't make you real understanding for design patterns, you can't The correct and appropriate design pattern in your own design. This article tries to view the design mode from another angle (design mode intent, motivation), through this new idea, design mode will become very close to your design process, and can guide, simplify your design, will eventually Export an excellent solution.
1. Introducing the development activities of the project, some design is very good in the project, but with the progress of the project, it is found that the existing code is modified or expanded, which mainly has the main reason: The needs of new features and further understanding of the system. At this time, we tend to find this work more difficult, even if you can complete it. At this point, a must be done is to reconstruct the existing code, which makes our next work relatively easy by reconstruction. Reconstruction is to improve its internal structure without changing the external behavior of the software system code. The goal of reconstruction is to make the code structure more reasonable, flexible, and adapt to new demands, new changes. Design patterns for a particular problem to give a beautiful solution will often become a refactoring goal, and once we can identify design patterns that can solve our problem, we will greatly simplify our work, because we can reuse others have already done the work. But in our original design and ultimately, the transition between our design patterns is not smooth, but there is a gap. Such a result is: Even if we know a lot of design patterns, facing our practical problems, we have no effective way to judge which design model applies to our system, we should apply it. The reason for causing the above problem is often due to the result of the solution given by the design mode, and the intention of the design mode, and the motivation it produces is ignored. However, it is the intention of the design model, the motivation has prompted people to give a solution for solving a type of problem, the motivation of design patterns, intention to reflect the formation of this model, so it is more close to our practical problem, thus will be effective Guide our reconstruction process. This article will be displayed by an example. In this paper, the example is simplified, so that this is to highlight the substance of the problem and will make our ideas clearer. The idea itself is the most important, most fundamental, simplified example does not reduce the idea of the idea that we show. 2. Problem Description A perfect software system must be handled according to an error, only in this way can make the system enough, I am going to use the software system as an example to show the ideas I use. ,method. In a distributed network management system, an operation is often not successful, often because there is such a reason for failure, at this time, we should process the corresponding process according to the cause of failure, so that the impact of the error is within the smallest range It is best to recover without affecting the normal operation of the system, it is important, that is, do not forget the manager of the notification system while processing the error, because only managers have the ability to further further Analysis, so that the root cause of the error is found, it is fundamentally solved. Below I will start from the wrong advertisement manager, start our journey. Assuming an operation of accessing a database in a distributed environment, it is possible to fail because of communication or the cause of the database itself. At this time we want to notify the manager's incorrect by the user interface. Simplified code examples are now as follows: / * Error code definition * /
Class ErrorConstant
{
Public static final int rt error_dbaccess = 100;
Public static final int error_communication = 101;
}
/ * Other functions in the user interface * /
Class Guisys
{
Public void AnnounceError (int errcode) {
Switch (errcode) {
Case errorConstant.error_dbaccess:
/ * Notice Manager database access error occurs * /
Break;
Case errorConstant.error_Communication:
/ * Notice Manager communication error occurred * /
Break;
}
}
}
Start, this code works very well, capable of completing the features we need. However, this code lacks corresponding elasticity, it is difficult to adapt to changes in demand. 3, the problem analysis, familiar with object-oriented readers will soon find the above code is a typical structured method, structured method is to organize the structure of the program with specific functions, and its package is only 1 However, there is only a package (function) for a particular function. This makes a structured method difficult to adapt to changes in demand, and object-oriented methods are in this point superior to structured methods. In the object-oriented domain, it is an object to form a program structure, an object has its own responsibilities, complete the system's functionality through the interaction between objects, which makes it packaged at least 2, that is, encapsulates to complete your own responsibilities Methods and data. Alternatively, the method of object also supports higher levels of packages, such as description by common concept behaviors of different specific objects, we can reach 3 level package - abstract classes (in Java is interface). The higher the level of the package, the higher the abstract level, which makes it designed, the higher the code, the more easily adapt to the change. Consider the code in the previous section, if you find a new error during the development of the system, such as: User authentication error, how should we make our system to increase the need for this feature? ? A relatively simple, direct approach is to add a CASE statement used to handle this error. Yes, this method can indeed work, but this is to pay for it. First, as the system is further developed, there may be more error types, then it will result in lengthy for the processing part of the error, which is not conducive to maintenance. Second, it is also the most fundamental point, and the code that has been able to work is easy to introduce the error, and in many cases, the error is incorrectly introduced, and it is difficult to locate this type of error. Some surveys show that we are not used in the development process, and most of the time is debugging and discovered errors. In the object-oriented field, there is a very famous principle: OCP (Open-Closed Princi), its core meaning: a good design should be able to accommodate the increase in new functional requirements, but the increase in way is not by modifying Module (class), but is done by adding new modules (classes). If a design can follow the OCP, you can effectively avoid the above problems. If a design can meet the principle of OCP, we require us to function as the core when designing design. The key to achieving the OCP is abstraction, abstraction characterizes a fixed behavior, but there are many different specific implementation methods for this behavior. With abstract, we can use a fixed abstract concept to replace which easy changes in many specific concepts, and make the modules that depend on which easy-to-change concepts, depending on this fixed abstract concept, so The result is: The increase in new demand will only cause an increase in the specific concept without affecting other modules of abstracts dependent on the concrete concept. On the level implemented, the abstract body is described by an abstract class, and in Java is an interface. For a more detailed description of OCP, see References [2]. Since you know the nature of the problem and the corresponding solution, you will improve our code structure. 4, the initial program allows us to re-examine the code to see how it is abstract.
In the error handling, you need to handle different types of errors, each particular error has some information specific to yourself, but they are consistent on the concept level, such as: can be obtained from the interior through a specific method interface. Error message, each error has its own processing method. This allows a preliminary scheme to define an abstract error base class, which defines some methods that can be conceptually suitable for all different specific errors in this base class, each particular error can have its own different Realization of these methods. The code example is, for example, Interface ErrorBase
{
Public void handle ();
Public String getInfo ();
}
Class DBAccesserror Implements Errorbase
{
Public void handle () {
/ * Processing about database access errors * /
}
Public string getInfo () {
/ * Construction Back to Information about Database Access Error * /
}
}
Class CommunicationError Implements Errorbase
{
Public void handle () {
/ * Treatment on communication errors * /
}
Public string getInfo () {
/ * Construction returns information about communication errors * /
}
}
In this way, we can construct an actual error object at an error, and reference it with ErrorBase. Then, give the error handling module. At this time, the error handling module only knows a type ERRORBASE, without having to know each specific error type, so you can use a unified way to handle errors. The code example is, for example:
Class Guisys
{
Public void Announceerror (ErrorBase Error) {
/ * Handling errors in the same way * /
Error.handle ();
}
}
It can be seen that the increase in new error types only needs to add a specific error class, which does not have any impact on the error handling section. It looks perfect, it also meets the principle of OCP, but further analysis will find that there is a problem in this program, and we will perform a detailed description in the next section. 5. Further analysis of the previous section gives a solution, which is perfect for only guisys, but the situation is often not the case. The front also mentioned that for the occurrence of the income, in addition to the user to inform the system, other processing, such as trying to recover, such as logs, etc. It can be seen that these processing methods are very different from the error notice to the user, and there is no way to unify all different processing only with a Handle method. However, if we add different processing methods in ErrorBase, in a specific error class, the corresponding implementation of its own needs, it seems to be a good solution. The code example is, for example:
Interface Errorbase
{
Public void guihandle ();
Public void loghandle ();
}
Class DBAccesserror Implements Errorbase
{
Public void guihandle () {
/ * Notify the user interface database access error handling * /
}
Public void loghandle () {
/ * Notification Log System Database Access Error Processing * /
}
}
Class CommunicationError Implements Errorbase
{
Public void guihandle () {
/ * Inform the user interface communication error handling * /
}
Public void loghandle () {
/ * Notification Log System Communication Error Processing * /
}
}
Class Guisys
{
Public void Announceerror (ErrorBase Error) {
Error.GuiHandle ();
}
}
Class logsys
{
Public void Announceerror (ErrorBase Error) {
Error.loghandle ();
}
}
The reader may have noticed that this practice is not very compliant with OCP, although it limit the change in ERRORBASE, but adds new processing methods, or changed the existing ErrorBase class. In fact, this design method also violates another famous object-oriented design principle: SRP (SINGLE RESPONSIBILITY Princi). The core meaning of this principle is: A class should have only one responsibility. With regard to the meaning of responsibilities, there is a famous definition of object-oriented master Robert.c martin: the root of a class is to guide the changes of this class. If a class has more than one duty, then there will be multiple different reasons It is actually coupled to multiple duties to each other, which will reduce the cohesiveness of this class. The responsibility of the wrong class is to save and related error status, and provide methods to get these states. Different processing methods are also placed in the error class in the design, thus increasing the duties of the wrong class, even if there is no relationship with the error class itself, there is no change in error handling, increase, modification, will result in the modification of the error class. This design method will bring unexpected problems when demand changes. So can it be stripped from the wrong processing method? If the reader is more familiar with the design mode (the familiarity here is the intention, motivation, instead of how to implement a specific design mode), it should be faint that a better design is about to appear. 6. Design mode surfaces let us re-describe the problem: we already have a class hierarchy about the wrong class. Now we need to allow us to increase our new level without changing this level of hierarchical structure. Approach. It sounds familiar, good, this is the description of the intent of the Visitor design mode. Through analysis of this mode motivation, we can easily know that if you want to use Visitor mode, you need to define two class hierarchies: a class level of the element corresponding to the received operation (that is our error class), and the other corresponds to the definition pair The visitor of the elements (that is, our different processing methods for errors). In this way, we convert the problem perspective, that is, transform the problem of different error handling methods to require different error handling classes, this result is that we can add new error handling methods by adding new modules (classes). Instead of increasing new error handling methods (so, it is necessary to modify the existing class). Once this is, the following work is relatively simple, because Visitor mode has built a design context for us. At this time we can pay attention to the implementation of the Visitor mode to guide us below the specific implementation. The UML map and code examples of the final program structure are given below, and the method of errors belonging to the error itself is ignored, and each particular error handling method interacts through these methods and specific error class objects to complete their respective processing. Features. The final design of the program structure map final code example
Interface Errorbase
{
Public void handle (Errorhandler Handler);
Class DBERROR IMPLEMENTS ERRORBASE
{
Public void handle (ERRORHANDLER HANDLER) {
Handler.handle (this);
}
}
Class Commerror Implements ErrorBase
{
Public void handle (ERRORHANDLER HANDLER) {
Handler.handle (this);
}
}
Interface Errorhandler
{
Public Void Handle (DBRROR DBERROR);
Public void handle (Commerror Commeror);
}
Class Guisys Implements Errorhandler
{
Public void Announceerror (ErrorBase Error) {
Error.handle (this);
}
Public void handle (dberror dberror) {
/ * Notify the user interface to process the relevant database error processing * /
}
Public void handle (commerror) {
/ * Notify the user interface for processing related to communication errors * /
}
}
Class logsys imports errorhandler
{
Public void Announceerror (ErrorBase Error) {
Error.handle (this);
}
Public void handle (dberror dberror) {
/ * Notification Log System Performs Database Error Processing * /
}
Public void handle (commerror) {
/ * Notification Log System for processing related to communication errors * /
}
}
7. Conclusion Design mode is not just a solution about a specific problem. Its intent and its motivation are often more important, because once we understand the intention of a design pattern, then in the design process, Easy discoveries apply to our own design patterns, which greatly simplifies design work and can get a more ideal design. In addition, in the process of learning design mode, you should pay more attention to the things behind design patterns, namely some of the excellent guidelines for specific design patterns, which have detailed discussion in the first chapter of reference [1]. There are basically two points:
Discover change, encapsulation changes Priority use combination, rather than inheritance If you pay attention to learning from these aspects, you will get more useful knowledge than a single specific design model itself, and even in the unanimous schema In the case, we can also design a good system. References [1] Design Patterns, Gamma, et al, Addison Wesley [2] Design Principles and Design Patterns, Robert C. Martin, www.objectmentor.com about OF: Ming Sun, software engineer at a large communications Company engaged in data network management
China
DW China all content ............... DW China Technology Zone: Component Technology Java Technology Linux XML ............... DW China Special Topics: Safety Unicode Site Architecture ............... IBM full content search help IBM Home | Products & Services | Support & Download | Personalized Services
IBM: DeveloperWorks China website: Java: All articles use design pattern improved program structure (1)
content:
Introduction Problem Description Analysis Preliminary Plan Further Analysis Design Mode Floating Water Conclusion Reference About Authors
Also in The Java Zone:
Teaching tools and product code and components all articles practical skills
Sun Ming (Dhui@263.net)
software engineer
The design pattern is a solution that solves its elegant solutions after a specific issue has been summarized after countless experience. However, if you want to truly make the design pattern maximize, just know what the design pattern is, and how it is achieved, because you can't make you real understanding for design patterns, you can't The correct and appropriate design pattern in your own design. This article tries to view the design mode from another angle (design mode intent, motivation), through this new idea, design mode will become very close to your design process, and can guide, simplify your design, will eventually Export an excellent solution.
1. Introducing the development activities of the project, some design is very good in the project, but with the progress of the project, it is found that the existing code is modified or expanded, which mainly has the main reason: The needs of new features and further understanding of the system. At this time, we tend to find this work more difficult, even if you can complete it. At this point, a must be done is to reconstruct the existing code, which makes our next work relatively easy by reconstruction. Reconstruction is to improve its internal structure without changing the external behavior of the software system code. The goal of reconstruction is to make the code structure more reasonable, flexible, and adapt to new demands, new changes. Design patterns for a particular problem to give a beautiful solution will often become a refactoring goal, and once we can identify design patterns that can solve our problem, we will greatly simplify our work, because we can reuse others have already done the work. But in our original design and ultimately, the transition between our design patterns is not smooth, but there is a gap. Such a result is: Even if we know a lot of design patterns, facing our practical problems, we have no effective way to judge which design model applies to our system, we should apply it. The reason for causing the above problem is often due to the result of the solution given by the design mode, and the intention of the design mode, and the motivation it produces is ignored. However, it is the intention of the design model, the motivation has prompted people to give a solution for solving a type of problem, the motivation of design patterns, intention to reflect the formation of this model, so it is more close to our practical problem, thus will be effective Guide our reconstruction process. This article will be displayed by an example. In this paper, the example is simplified, so that this is to highlight the substance of the problem and will make our ideas clearer. The idea itself is the most important, most fundamental, simplified example does not reduce the idea of the idea that we show. 2. Problem Description A perfect software system must be handled according to an error, only in this way can make the system enough, I am going to use the software system as an example to show the ideas I use. ,method. In a distributed network management system, an operation is often not successful, often because there is such a reason for failure, at this time, we should process the corresponding process according to the cause of failure, so that the impact of the error is within the smallest range It is best to recover without affecting the normal operation of the system, it is important, that is, do not forget the manager of the notification system while processing the error, because only managers have the ability to further further Analysis, so that the root cause of the error is found, it is fundamentally solved. Below I will start from the wrong advertisement manager, start our journey. Assuming an operation of accessing a database in a distributed environment, it is possible to fail because of communication or the cause of the database itself. At this time we want to notify the manager's incorrect by the user interface. Simplified code examples are now as follows: / * Error code definition * /
Class ErrorConstant
{
Public static final int rt error_dbaccess = 100;
Public static final int error_communication = 101;
}
/ * Other functions in the user interface * /
Class Guisys
{
Public void AnnounceError (int errcode) {
Switch (errcode) {
Case errorConstant.error_dbaccess:
/ * Notice Manager database access error occurs * /
Break;
Case errorConstant.error_Communication:
/ * Notice Manager communication error occurred * /
Break;
}
}
}
Start, this code works very well, capable of completing the features we need. However, this code lacks corresponding elasticity, it is difficult to adapt to changes in demand. 3, the problem analysis, familiar with object-oriented readers will soon find the above code is a typical structured method, structured method is to organize the structure of the program with specific functions, and its package is only 1 However, there is only a package (function) for a particular function. This makes a structured method difficult to adapt to changes in demand, and object-oriented methods are in this point superior to structured methods. In the object-oriented domain, it is an object to form a program structure, an object has its own responsibilities, complete the system's functionality through the interaction between objects, which makes it packaged at least 2, that is, encapsulates to complete your own responsibilities Methods and data. Alternatively, the method of object also supports higher levels of packages, such as description by common concept behaviors of different specific objects, we can reach 3 level package - abstract classes (in Java is interface). The higher the level of the package, the higher the abstract level, which makes it designed, the higher the code, the more easily adapt to the change. Consider the code in the previous section, if you find a new error during the development of the system, such as: User authentication error, how should we make our system to increase the need for this feature? ? A relatively simple, direct approach is to add a CASE statement used to handle this error. Yes, this method can indeed work, but this is to pay for it. First, as the system is further developed, there may be more error types, then it will result in lengthy for the processing part of the error, which is not conducive to maintenance. Second, it is also the most fundamental point, and the code that has been able to work is easy to introduce the error, and in many cases, the error is incorrectly introduced, and it is difficult to locate this type of error. Some surveys show that we are not used in the development process, and most of the time is debugging and discovered errors. In the object-oriented field, there is a very famous principle: OCP (Open-Closed Princi), its core meaning: a good design should be able to accommodate the increase in new functional requirements, but the increase in way is not by modifying Module (class), but is done by adding new modules (classes). If a design can follow the OCP, you can effectively avoid the above problems. If a design can meet the principle of OCP, we require us to function as the core when designing design. The key to achieving the OCP is abstraction, abstraction characterizes a fixed behavior, but there are many different specific implementation methods for this behavior. With abstract, we can use a fixed abstract concept to replace which easy changes in many specific concepts, and make the modules that depend on which easy-to-change concepts, depending on this fixed abstract concept, so The result is: The increase in new demand will only cause an increase in the specific concept without affecting other modules of abstracts dependent on the concrete concept. On the level implemented, the abstract body is described by an abstract class, and in Java is an interface. For a more detailed description of OCP, see References [2]. Since you know the nature of the problem and the corresponding solution, you will improve our code structure. 4, the initial program allows us to re-examine the code to see how it is abstract.
In the error handling, you need to handle different types of errors, each particular error has some information specific to yourself, but they are consistent on the concept level, such as: can be obtained from the interior through a specific method interface. Error message, each error has its own processing method. This allows a preliminary scheme to define an abstract error base class, which defines some methods that can be conceptually suitable for all different specific errors in this base class, each particular error can have its own different Realization of these methods. The code example is, for example, Interface ErrorBase
{
Public void handle ();
Public String getInfo ();
}
Class DBAccesserror Implements Errorbase
{
Public void handle () {
/ * Processing about database access errors * /
}
Public string getInfo () {
/ * Construction Back to Information about Database Access Error * /
}
}
Class CommunicationError Implements Errorbase
{
Public void handle () {
/ * Treatment on communication errors * /
}
Public string getInfo () {
/ * Construction returns information about communication errors * /
}
}
In this way, we can construct an actual error object at an error, and reference it with ErrorBase. Then, give the error handling module. At this time, the error handling module only knows a type ERRORBASE, without having to know each specific error type, so you can use a unified way to handle errors. The code example is, for example:
Class Guisys
{
Public void Announceerror (ErrorBase Error) {
/ * Handling errors in the same way * /
Error.handle ();
}
}
It can be seen that the increase in new error types only needs to add a specific error class, which does not have any impact on the error handling section. It looks perfect, it also meets the principle of OCP, but further analysis will find that there is a problem in this program, and we will perform a detailed description in the next section. 5. Further analysis of the previous section gives a solution, which is perfect for only guisys, but the situation is often not the case. The front also mentioned that for the occurrence of the income, in addition to the user to inform the system, other processing, such as trying to recover, such as logs, etc. It can be seen that these processing methods are very different from the error notice to the user, and there is no way to unify all different processing only with a Handle method. However, if we add different processing methods in ErrorBase, in a specific error class, the corresponding implementation of its own needs, it seems to be a good solution. The code example is, for example:
Interface Errorbase
{
Public void guihandle ();
Public void loghandle ();
}
Class DBAccesserror Implements Errorbase
{
Public void guihandle () {
/ * Notify the user interface database access error handling * /
}
Public void loghandle () {
/ * Notification Log System Database Access Error Processing * /
}
}
Class CommunicationError Implements Errorbase
{
Public void guihandle () {
/ * Inform the user interface communication error handling * /
}
Public void loghandle () {
/ * Notification Log System Communication Error Processing * /
}
}
Class Guisys
{
Public void Announceerror (ErrorBase Error) {
Error.GuiHandle ();
}
}
Class logsys
{
Public void Announceerror (ErrorBase Error) {
Error.loghandle ();
}
}
The reader may have noticed that this practice is not very compliant with OCP, although it limit the change in ERRORBASE, but adds new processing methods, or changed the existing ErrorBase class. In fact, this design method also violates another famous object-oriented design principle: SRP (SINGLE RESPONSIBILITY Princi). The core meaning of this principle is: A class should have only one responsibility. With regard to the meaning of responsibilities, there is a famous definition of object-oriented master Robert.c martin: the root of a class is to guide the changes of this class. If a class has more than one duty, then there will be multiple different reasons It is actually coupled to multiple duties to each other, which will reduce the cohesiveness of this class. The responsibility of the wrong class is to save and related error status, and provide methods to get these states. Different processing methods are also placed in the error class in the design, thus increasing the duties of the wrong class, even if there is no relationship with the error class itself, there is no change in error handling, increase, modification, will result in the modification of the error class. This design method will bring unexpected problems when demand changes. So can it be stripped from the wrong processing method? If the reader is more familiar with the design mode (the familiarity here is the intention, motivation, instead of how to implement a specific design mode), it should be faint that a better design is about to appear. 6. Design mode surfaces let us re-describe the problem: we already have a class hierarchy about the wrong class. Now we need to allow us to increase our new level without changing this level of hierarchical structure. Approach. It sounds familiar, good, this is the description of the intent of the Visitor design mode. Through analysis of this mode motivation, we can easily know that if you want to use Visitor mode, you need to define two class hierarchies: a class level of the element corresponding to the received operation (that is our error class), and the other corresponds to the definition pair The visitor of the elements (that is, our different processing methods for errors). In this way, we convert the problem perspective, that is, transform the problem of different error handling methods to require different error handling classes, this result is that we can add new error handling methods by adding new modules (classes). Instead of increasing new error handling methods (so, it is necessary to modify the existing class). Once this is, the following work is relatively simple, because Visitor mode has built a design context for us. At this time we can pay attention to the implementation of the Visitor mode to guide us below the specific implementation. The UML map and code examples of the final program structure are given below, and the method of errors belonging to the error itself is ignored, and each particular error handling method interacts through these methods and specific error class objects to complete their respective processing. Features. The final design of the program structure map final code example
Interface Errorbase
{
Public void handle (Errorhandler Handler);
Class DBERROR IMPLEMENTS ERRORBASE
{
Public void handle (ERRORHANDLER HANDLER) {
Handler.handle (this);
}
}
Class Commerror Implements ErrorBase
{
Public void handle (ERRORHANDLER HANDLER) {
Handler.handle (this);
}
}
Interface Errorhandler
{
Public Void Handle (DBRROR DBERROR);
Public void handle (Commerror Commeror);
}
Class Guisys Implements Errorhandler
{
Public void Announceerror (ErrorBase Error) {
Error.handle (this);
}
Public void handle (dberror dberror) {
/ * Notify the user interface to process the relevant database error processing * /
}
Public void handle (commerror) {
/ * Notify the user interface for processing related to communication errors * /
}
}
Class logsys imports errorhandler
{
Public void Announceerror (ErrorBase Error) {
Error.handle (this);
}
Public void handle (dberror dberror) {
/ * Notification Log System Performs Database Error Processing * /
}
Public void handle (commerror) {
/ * Notification Log System for processing related to communication errors * /
}
}
7. Conclusion Design mode is not just a solution about a specific problem. Its intent and its motivation are often more important, because once we understand the intention of a design pattern, then in the design process, Easy discoveries apply to our own design patterns, which greatly simplifies design work and can get a more ideal design. In addition, in the process of learning design mode, you should pay more attention to the things behind design patterns, namely some of the excellent guidelines for specific design patterns, which have detailed discussion in the first chapter of reference [1]. There are basically two points:
Discover change, encapsulation changes Priority use combination, rather than inheritance If you pay attention to learning from these aspects, you will get more useful knowledge than a single specific design model itself, and even in the unanimous schema In the case, we can also design a good system. Reference [1] Design Patterns, Gamma, et. Al., Addison Wesley [2] Design Principles and Design Patterns, Robert C. Martin, www.Objectmentor.com
Page
