Humidifier and program design ideas

Beijing is too dry in winter, so I bought a humidifier, such:

 

 

This humidifier is still relatively creative design, unlike the ordinary humidifier, it only has the body, there is no place to hold water. To add water, you need to add a bottle of water, and this bottle is the beverage bottle we usually use to drink water, so it is very convenient to use. We can connect a water bottle to produce water mist anytime, anywhere, and we can change the bottle at will, such:

 

 

Well... Although the bottle is a little big, its mood is still stable... In fact, such a humidifier still contains some truth about program design, at least including data and logic separation, single responsibility principle, Interface Programming and adapter mode;

 

 

Data and logic Separation

 

Here the data is water (not a bottle), the data is not contained in the humidifier, it is packed in a bottle outside the humidifier. If we want to change a kind of water, for example, not a general tap water, but a mixed liquid with fragrance or color, we just need to replace the water in the bottle with what we want, then connect the bottle and press the switch. In addition, in this process, we do not need to change the inside of the humidifier to complete, if you need to change the water, you need to take the humidifier apart, and then find the place where you can add water, and then pour the water, close the lid and tighten the screws ..... This is a lot of trouble !! That is to say, we should not involve specific data in the Code logic, because the data will change frequently. If you need to change the data first to a class, find/replace it, then there is a problem with this design, and it should be abstracted, such as text and templates.

 

 

Single Responsibility Principle (SRP)

 

The single responsibility principle means that one class is best to do only one thing, and there is only one reason for its change. If a class assumes multiple responsibilities, there are also multiple reasons for its changes. Here the bottle only needs to take charge of water, and then provide water to the humidifier through the injection nozzle, only water change can cause its changes; the humidifier body, the humidifier body is responsible for receiving the water in the bottle, to what water, it does not care, it is only responsible for converting water to fog; power supply, power adapter provides power for the humidifier, the humidifier itself does not need to store power, rely on the power input port to access the power supply.

OK, now the responsibilities of the three functional blocks are separated. If the humidifier does not work at this time, we can check whether there is no water, no electricity, or the atomizer does not work. If there is no water, we just need to add water to the bottle, and then take back the humidifier nozzle, here do not need to make any changes to the humidifier body; if there is no electricity, we can plug in the power, or change the power supply, and then insert the humidifier, here do not need to change the body of the humidifier; if the atomizer does not work, then the core of the humidifier may be down, the fastest solution is to change the body of the humidifier, and then connect the water bottle, connect to the power supply to continue to use.

 

The responsibilities are as follows:
 
Water bottled water to provide water for the humidifier;

Power supply, providing power for the humidifier;

The main body of the humidifier converts the electric energy into kinetic energy and then atomizing the water. Among them, water and electricity are provided by external functions. It is only responsible for conversion and does not care about how it comes.

 

Then combine the three into a complete humidifier. If there is no separation of duties, integrate the three (now there is a humidifier ). This is like designing a large class that fully implements water processing, electric processing, and atomization processing. If you want to modify one of the functions, you need to change it to this class, in addition, the Code may be too large. If we abstract these three functions into three classes, development and maintenance will be easier. We only need to modify the functions we want to change, such as water processing, I will not modify the electric processing class and atomization processing class. If we set the amount of information for the three functions to 100, it may be 30 for water processing, 30 for electric processing, and 40 for Atomization, so 30 or 40 of the information must be easier to process than 100 of the information, which is one reason why everyone advocates a small amount of code for each functional block.

 

 

Interface Programming

 

For interface programming, do not implement programming (nonsense ....).. Uh .. To put it simply, we need to make the functions flexible. For example, I can use a small bottle for a humidifier (Figure 1), a large bottle (Figure 2), or a variety of strange bottles. However, one cannot be changed, that is, the bottle port, because we need to twist the bottle port connector provided by the humidifier, And Then buckle it to the humidifier, this bottle port connector contains a spiral convex slot, it is the same as the general mineral water bottle lid, so it can be closely integrated with the bottle (for the bottle port connector ).

 

The bottle port standard here is the interface. Only when this standard is met can it be used by the bottle port connector. The advantage of doing so is that I can change the bottle at will, and only care about whether the bottle is in line with the bottle connector needs the standard, do not care about the bottle length. What is the bottle itself long, and has nothing to do with the bottle port connector or humidifier body, so the bottle can be large, small, circle, square, as long as the bottle mouth meets the standards on the line, in this way, different requirements are met. If we make the bottle directly above the humidifier, it cannot be separated, then it cannot be changed, it cannot meet different needs. Different bottles here are actually different categories. The bottle mouth standard (specifying the size of the bottle and the depth of the spiral convex slot) is the interface (note that it is the bottle mouth standard, not the bottle mouth, the bottle port is only the implementation of this interface ). If we write the implementation of the bottle in the humidifier class, we need to change the humidifier class when we change the bottle. If the change is frequent, the changes are also frequent, which is quite inconvenient, increased maintenance costs. Now the implementation of the bottle is abstracted. the humidifier class does not care about the implementation of the bottle. It only cares about providing a bottle port connector and then connecting the bottle, if you want to change the bottle, you do not need to modify the humidifier. You can take the old bottle out of the interface, and then change the bottle that implements this interface to work normally, in this way, later maintenance is much easier .. In existing designs, such as obtaining data (SQL/access/XML/JSON), rendering of interaction effects (general presentation, progressive transparency/progressive presentation), etc, you can use interfaces to Achieve flexible switching.

Adapter Mode

 

The so-called adapter mode roughly means "converting an interface of a class into another interface that the client expects, so that the two classes that cannot work together due to interface mismatch can work together ". Now let's take a look at this bottle port connector. It is an adapter that connects the bottle port of the bottle with the water injection of the humidifier, because the bottle port cannot be directly connected to the humidifier, so you have to convert it once. The connector is a new type. The adapter mode is used to connect the bottle with the humidifier .... By the way, in fact, the design model is not something too profound and mysterious. It can be said to be an accumulation of experience, and we may intentionally or unintentionally use it, it is mainly for the purpose of making code easy to maintain and function expansion convenient. We do not have to deliberately "Learn" It, But to "experience" it, "feel" it.

To tell the truth, it is easy to understand some principles, but it is very difficult to describe them. The above ideas are for reference only... Hoho ~~