10 object-oriented theories that Java programmers should know

English Original: 10-object-oriented-design-principles

Object-oriented theory is the core of object-oriented programming, but I find that most Java programmers are passionate about design patterns such as singleton, decorator, or observer patterns, and do not pay much attention to object-oriented analysis and design. It is important to learn the basics of programming-oriented (such as abstraction, encapsulation, polymorphism, inheritance, etc.), and it is equally important to use them to design clean modules. I also know many different levels of programmers who have not heard of these object-oriented theories, or have no idea what the benefits of a design theory are, or how to use these design theories in coding.

At the very least, we need to design a highly consistent and loosely coupled code. The source code for Apache and Sun is a very good example of learning Java object-oriented theory. The JDK follows some design patterns, such as the use of Factory mode in Borderfactory, the Runtime class using the singleton pattern, and the decorator pattern in many classes in java.io. If you're really interested in Java programming, read Joshua Bloch's effective Java, which is where he has written the Java API. Two other books I like about design patterns and the head first design pattern and head first Object oriented analysis and design written by Kathy Sierra. These books help to understand the object-oriented theory and help me write better code.

The best way to learn any design theory or model is in the real world, and this article simply introduces the theory of face object to programmers who are still in the learning phase. I think each of the following need an article to be introduced in detail, I will be introduced in the future, but now a quick look at the first.

Avoid duplication, DRY (Don ' t repeat yourself)

The first rule of face-to-design theory is to avoid duplication, do not write repetitive code, and try to put common functions in one place. If you are going to write the same piece of code in different places, write only one method. If you hardcode a value more than once, declare it as a public final constant. The advantage of doing so is that it is easy to maintain. But do not abuse this one, repetition does not mean the repetition of the code, but the repetition of the function. For example, you have the same code to verify OrderID and SSN, but they represent different meanings. If you merge two different functions together, when OrderID changes the format, then the code that examines the SSN is invalidated. So be aware of this coupling, and don't say anything similar but unrelated to the code merging together.

Wrap the changes together

The only constant in the field of software is "change." So it's best to encapsulate the code that you think will change in the future. The advantage of this is that it is easier to test and maintain the correct encapsulated code. You should declare the variable as private and then expand access if necessary, such as turning private to protected. Many design patterns in Java are encapsulated, and factory design patterns are an example of encapsulation, which encapsulates the creation of objects and the need to change existing code if a new "product" is introduced.

Open and closed design theory (open Closed designs Principle)

Classes, methods, and features should be open to extensions (new functionality) and closed for changes. This is another beautiful "SOLID" design theory, which ensures that someone changes the code that has been tested. If you want to add a new feature, you have to test it first, which is the goal of an open and closed design theory. In addition, Open Closed principle is the abbreviation for the O in SOLID.

Single Responsibility principle (Responsibility Principle (SRP))

The single responsibility principle is another "SOLID" Design theory, which represents the "S". Each time a class has only one reason to change, or a class should only complete a single function. If you put more than one function in a class, it will couple two functions together, and if you change one of these features, you might break another one, which will require more testing to ensure that nothing goes wrong when you go online.

Dependency Injection or reversal principle

The container provides dependency injection, and Spring implements the dependency injection very well. The beauty of this principle is that each injected class is easy to test and maintain because the creation code for these objects is concentrated in the container, and there are several ways to do it, such as byte-code injection for some AOP frameworks such as AspectJ (bytecode instrumentation), as well as the proxy used in Spring. Take a look at this example of a dependency injection. This is the "D" in SOLID.

Multi-use combination, less inheritance

If possible, use multiple combinations and less inheritance. There may be people who disagree, but I do find that the combination of flexibility is higher than inheritance. A combination can be used to set a property at run time and to combine a class through an interface, and we can use polymorphism so that the behavior of the class can be changed at any time, greatly increasing flexibility. Effective Java is also more inclined to use combinations.

Liskov substitution principle (Liskov Substitution Principle (LSP))

Depending on the principle of Liskov substitution, subclasses must be able to override the parent class, that is, using the parent class's methods, as well as being compatible with the subclass object without any problems. LSP is closely related to the principle of single responsibility and the principle of interface separation. If the function of an analogy subclass is more, the subclass cannot support certain functions in the parent class, it violates the LSP. To follow the LSP principle, subclasses need to improve the functionality of the parent class rather than reduce the functionality. The LSP represents the "L" in SOLID.

Interface separation theory (Interface segregation principle (ISP))

The theory of interface separation emphasizes that if the client does not use an interface, do not implement it. When an interface contains more than two functions, if the client needs only one of these features and does not need another, then do not implement it. Interface design is a very complex task, because once you have published an interface, there is no guarantee that you can change the interface without breaking the existing implementation. Another benefit of separating the interfaces is that, because the method must be implemented to use the interface, the methods to be implemented are reduced if there is only a single function.

Programming for interfaces, not for implementation

Try to program the interface as much as possible, so that if any new interfaces are introduced, there is enough flexibility. Use the interface type in the type of the variable, the return type of the method, and the parameter type. Many programmers recommend this, including books such as effective Java and head first design pattern.

Agency theory (Delegation principle)

Do not do everything yourself, sometimes you have to delegate the task to the appropriate class to do it. The most classic example of using proxy mode is the Equals () and Hashcode () methods. To compare the equality of two objects, we did not compare them with the client code, but rather let the objects compare themselves. The advantage of this is that it reduces the duplication of code and makes it easier to change behavior.

All of these face-object theories can help you write more flexible, highly consistent, and low-coupling code. Theory is the first step, and more importantly, the ability to apply these design theories. Find out what violates these design theories, but like nothing in the world is perfect, don't try to solve everything with design patterns and theories, because they are often targeted at large enterprise projects with longer running cycles. In other words, small projects are not necessarily worth doing.

Translation: importnew.com-Tangxiaojuan Translations Link: http://www.importnew.com/6445.html

10 object-oriented theories that Java programmers should know