Analysis of JAVA design mode (I)

Analysis of JAVA design mode (I)
First, I wrote a technical blog to share with you what I have accumulated every day. Today, when I read the book "large website architecture and java middleware", I mentioned the dynamic proxy mode. As an important basis of java middleware, I think it is necessary to sort out and analyze the 23 java design patterns. If there is anything wrong, please leave it correct. I. Classification of design patterns in general, Java's design patterns are divided into three categories: Creation patterns, structural patterns, and behavior patterns. Creation patterns: factory method mode, abstract factory mode, Singleton mode, builder mode, and prototype mode. Structural mode: adapter mode, decoration mode, proxy mode, appearance mode (also known as facade mode), Bridge Mode (Bridge Mode), combination mode, and metadata mode. Behavior mode: rule mode, template method mode, observer mode, iterator mode, responsibility chain mode, command mode, memorandum mode, state mode, visitor mode, intermediary mode, interpreter mode. Before talking about the design pattern, let's talk about the six principles of the java design pattern. Ii. Six principles of JAVA Design Patterns 1. Single Responsibility Principle: SRP (Single Responsibility Principle) has a Single Responsibility and is defined as having one and only one factor causing changes to the class or interface. As the name implies, a single method is defined for different classes or interfaces. Here, a single method does not mean that only one method is defined, but also a type of behavior method. For example, Class A is responsible for two different responsibilities: Responsibilities A1 and responsibilities A2. When Class A needs to be modified due to A change in responsibilities A1, the function of class A2 may change, resulting in program exceptions. In this case, you need to split Class A into two different classes or interfaces to perform different duties. For example, 1 public interface IStudent {2 // height 3 void theweigh (double height); 4 double getheweigh (); 5 // weight 6 void setWeight (double weight); 7 double getWeight (); 8 // dinner 9 boolean brunch (boolean hungry ); 10 // game 11 boolean playGame (boolean free); 12} The responsibility defined by this interface is not clear. Therefore, we can split it into two interfaces, IStudentBo and IStudentAction. Attribute interface IStudentBO: public interface IStudentBO {// height void setHeight (double height); double getHeight (); // weight void setWeight (double weight); double getWeight ();} behavior interface IStudentAction: public interface IStudentAction {boolean brunch (boolean hungry); boolean playGame (boolean free);} then define implementation classes to implement various interface methods. In this way, attribute methods and behavior methods are separated, and their classes will not be changed due to multiple points. This is a single responsibility. Is it easy. Of course, we can only follow the single responsibility principle as much as possible. It depends on the project requirements. At least some of the design patterns mentioned later violate the single responsibility principle.