In real work, do you operate like this: when a requirement comes, change the original code again, and when another requirement comes, change the code of the previous requirement again. Many repetitive tasks are still repeated day after day. Any good way to improve it?
I believe experienced friends must have heard it: open for extension, closed for modification. So, do you know what this sentence really means? Today we will talk about how the opening and closing principle is realized.
What is the open-closed principle
The open-closed principle (OCP) was proposed by Bertrand Meyer in 1988. The design principle states:
Software entities should be open for extension, but closed for modification.
Software entities should be open for extension and closed for modification.
How to Implement the Open-Closed Principle
"Open to extension, closed to modification", how to understand? Let's look at a case first, as shown in the figure below, which shows a simple model diagram of inventory changes in the e-commerce inventory system. The inventory system receives external system inventory change events, and then modifies the inventory in the database.
Faced with this business requirement, many people's code will be written like this
public class Stock {
public void updateStock(String event){
if("outOfStock" == event){
// todo 出库事件 库存操作
}else if("warehousing" == event){
// todo 入库事件 库存操作
}
}
}
At this time, new requirements come: inventory events (inventory surplus/inventory deficit) will be generated inside the WMS storage system, and these events will lead to inventory changes. Therefore, the code will develop into the following
public class Stock {
public void updateStock(String event){
if("outOfStock" == event){
// todo 出库事件 库存操作
}else if("warehousing" == event){
// todo 入库事件 库存操作
}else if("panSurplus" == event){
// todo 盘盈事件 库存操作
}else if("loss" == event){
// todo 盘亏事件 库存操作
}
}
}
Obviously, for the implementation of the above code, every time a requirement comes, the code needs to be modified once, and an else if branch is added to the method, so the Stock class is always changing and unstable.
Is there any good way to make this code not need to be modified, but can be flexibly expanded to meet business needs?
At this time, we will move out the three magic weapons of java: inheritance, implementation, and polymorphism .
We found that the whole business model is: Events cause inventory changes. So, can the event be extracted? Therefore, the event model can be abstracted into an interface, the code is as follows
public interface Event {
public void updateStock(String event);
}
Each event corresponds to an inventory change, abstracted into a specific implementation class, the code is as follows
Inbound events
public class WarehousingEvent implements Event {
public void updateStock(String event){
// 业务逻辑
}
}
outbound event
public class OutOfStockEvent implements Event {
public void updateStock(String event){
// 业务逻辑
}
}
xxx event
public class XXXEvent implements Event {
public void updateStock(String event){
// 业务逻辑
}
}
Finally, the updateStock() inventory change logic in the Stock class can be abstracted as follows
public class Stock {
public void updateStock(String event){
// 根据事件类型获取真实的实现类
Event event = getEventInstance(event);
// 库存变更操作
event.updateStock();
}
}
After our abstraction, separation and transformation, the Stock.updateStock() class is stabilized, and there is no need to add an event and then add an else if branch for processing. The benefits of this abstraction are also obvious: every time there is a new inventory change event, only one implementation class needs to be added, and other logic does not need to be changed. When the inventory event is invalid, only the implementation class needs to be deleted.
Summarize
Through the above case, we have demonstrated the entire abstraction and implementation process of the opening and closing principle. The business may be a bit simple, but the representative meaning is very strong.
The core of the open-closed principle is to open for extension and close for modification. Therefore, when your business needs always need to modify the same piece of code, you have to carefully observe whether the business has similar problems to the above cases. What are the reasons for thinking more about code modification? Are there any commonalities between them? Can these change points be separated and implemented by extension instead of modifying the code?
In fact, there are many similar scenarios in business development, such as: membership system in e-commerce system, which needs to calculate different fees according to different levels of users; ticket system, according to different levels of users (ordinary, platinum users, gold users... ) provides different ticketing mechanisms; in the gateway system, current limiting is implemented according to different granularities (interface, ip, service, cluster);
Some friends may refute that my business scenario has a similar scenario, but the logic is simple, and a few if else can be done. There is no need to engage in such a complicated design.
My suggestion: work hard in peacetime, work hard in details.
Many people always complain about the slow growth of business development technology, especially for junior programmers, but the starting point of most people is business CRUD. If you can find a way to "dig" and "apply" certain design patterns in the business curd
process , Through this kind of long-term deliberate practice, quantitative changes will produce qualitative changes, and gradually you will be able to understand the mystery of these classic design principles. Produce pleasing code.