This is the 8th day of my participation in Gwen Challenge.More article challenges
Take a look at the relationship between Windows, PhoneWindow, and DecorView
First, the cause?
1. Many people dismiss the single responsibility principle. Because it’s too easy; An experienced programmer who has never read a design pattern or heard of a single responsibility principle. 3. Follow this important principle when designing software, because it is common sense. In software programming, you don’t want to change one function so that something else breaks down. The way to avoid this problem is to follow the single responsibility principle. 4. Although the single responsibility principle is so simple and may seem like common sense, even experienced programmers write programs that violate it.
What is the single principle? Why use
- Literally, the single-responsibility principle means that you are responsible for your own business and don’t have to deal with other people’s business. This single responsibility principle should be easy to understand if you know object-oriented programming;
- In object-oriented programming, each object is only responsible for its own tasks, such as providing data only to provide data, the responsible for providing services only to provide services, or just maintain the relationship between objects, such a development mode of code coupling degree is lower, more flexible, easy to expand. Of course, one object can be responsible for more than one task, but it is easier to modify the task to affect other tasks.
- Single responsibility, the pursuit of simple and clear design, emphasis is clear division of labor, simple responsibility. This design, not limited to class design, can be extended to any program logic unit design, such as function design, module design, engineering design, project design, cluster design and so on.
Advantages of single principle?
- You can reduce the complexity of a class, a class is responsible for only one responsibility, its logic is certainly much simpler than responsible for multiple responsibilities;
- Improve class readability and system maintainability;
- The risk reduction caused by change is inevitable. If the principle of single responsibility is well followed, when modifying one function, the impact on other functions can be significantly reduced.
- It is important to note that the single responsibility principle is not unique to object-oriented programming but applies to modular programming.
Iv. Detailed case analysis
For example, the common Taobao shopping cart
Initially the interface was defined as follows
Public interface ICartShopping {/**** toSelGoods * @param o*/void toSelGoods(Object o); /**** calculate price * @param o*/void calprice(Object o); /**** checkPrice */void checkPrice(); /**** */void goodDetails(); /**** coupon information */void couponDetails(); . }Copy the code
Analysis is as follows:
1. At first glance, it seems that the interface design is quite reasonable. There are no major problems
2. In the actual development, settlement, commodity information and coupons are developed by different people, and the functions inside are also very complicated. Frequent changes of ICartShopping interface will affect others, which is poor in decoupling and does not follow a single principle
Change the following
Public interface IGoodsShopping {/**** load goodDetails */void goodDetails(); . } public interface ICouponShopping {/**** coupon info */void couponDetails(); . } public interface ISelShopping {/**** 下 载 * @param o*/void toSelGoods(Object o); /**** calculate price * @param o*/void calprice(Object o); /**** checkPrice */void checkPrice(); . }Copy the code
Problems are not terrible, terrible is that the discovery of problems do not change, not progress
The single principle is summarized as follows:
The core of a single responsibility can be understood as follows: divide the whole into parts and decompose the whole into local logical units. Different logical units should be relatively independent as far as possible and have clear responsibilities. For example, a project can be decomposed into multiple projects; A project can be decomposed into multiple modules; A module that can be decomposed into multiple packages and classes; A class can be decomposed into multiple properties and method behaviors, and the decomposition at the design level can correspond to the separation at the concrete implementation level.
Take a look at the relationship between Windows, PhoneWindow, and DecorView