Finally, I completed a big project of the company, and gained a lot during this period. I had a deeper understanding of “component development”.
In today’s front-end development, “componentization” has become a popular concept, and the various development frameworks that follow it carry forward this concept. However, the concept belongs to the concept, and there are still many places worth discussing in the real “componentization” practice, of which “black box” is the most representative one I think. Today, let’s put aside the specific framework and talk directly about “component development” and “black box”.
First of all, I would like to quote an introduction from Wikipedia:
Component-based Software Engineering (CBSE) or Component-Based Development (CBD) is a software development paradigm. It is a hot research topic in the application of software reuse theory. With the support of component object mode l, software developers can quickly construct application software “plug and play” by reusing existing components. This can not only save time and money, improve work efficiency, but also produce more standardized and reliable application software.
In the development of business, we often extract some parts that need to be reused and package them separately, and then introduce them when necessary. This is equivalent to “componentizing” this reusable part. Component-based operations can greatly reduce the amount of development, while a good component can also effectively improve stability. In modern web development, “components” usually contain logical functions and styles, and various UI libraries are the best examples. For example, a drop-down menu with complicated interaction will add huge time and labor costs if you have to rewrite a set of codes before each use. However, through the UI library, it only needs to be simply introduced and quoted according to the agreed writing style, thus greatly liberating productivity.
In addition, “componentization” can effectively reduce or even eliminate coupling. We know that “one hair touches the whole body”. If the coupling between each module of a system is too tight, once there is a problem in one place, it will be very difficult to investigate and the consequences may be disastrous. The idea of “componentization” can well avoid this problem. Because the components are independent of each other and are only connected through interfaces, once a component has a problem, only the fault of the component needs to be checked, and other components can work normally or wait for the component to be repaired before working.
Second, pure function
In programming, a function may be considered pure if it meets the following requirements:
- This function needs to produce the same output at the same input value. The output of the function has nothing to do with other hidden information or states other than the input value, and also has nothing to do with the external output generated by the I/O device.
- This function cannot have semantically observable function side effects, such as “triggering events”, causing output devices to output, or changing the contents of items other than output values, etc.
Mathematically, if you define a function:
f(x) = x + x
So no matter when and where any conditions, as long as I enter 1, then I will definitely output 2:
f(1) == 2
It is precisely because of this “pure” characteristic that “high order” is allowed:
f(x) = x + x g(x) = x * 2 h(x) = x * x h(g(f(1))) = 16
There are a lot of articles about pure functions and functional programming on the network, so this article will not repeat them. From my personal point of view, as long as I can understand what is “pure”.
Third, the black box
Continue to quote a sentence from Wikipedia to introduce:
Black box refers to a system or device that only knows the input-output relationship but does not know the internal structure.
Many things in life can be understood as “black boxes”. For example, we often use cell phones. We may not know how it works. We only know that when my finger strokes, it will make corresponding actions. At this moment, the finger stroke is “input” and the corresponding action is “output”. Because input and output are so intuitive and simple, mobile phones can be easily used by everyone.
Our work cannot be separated from the computer. Now the computer can be switched on as long as it is plugged in. However, the first computer in human history is a colossus that requires professionals to spend some time to run it-because users need to fully understand the internal operation principle of this machine before they can use it correctly.
The above two examples are actually intended to illustrate one point: black boxes are more beneficial to use.
However, everything has two sides. Black boxes sacrifice the user’s understanding of their internal structure and principles for ease of use. If there is a fault inside the black box, the user cannot know the specific reason, which is very unfavorable to the troubleshooting of the system. Therefore, the black box requires very high stability and reliability of the system.
IV. Engineering Practice
After the previous three sections, it should not be difficult to understand what I want to express. A black box is a pure function, and the abstracted components should conform to the settings of this black box:
Components are only connected through interfaces.
A component can receive multiple parameters, and the nesting and use of components are also carried out through interfaces. After processing the passed-in parameters, the component should pass the results through the interface (or event), andCan not directly affect the outside. For example, the following example, after
numWill not be changed.
num = 1 f(x) = x + 1 // f(num) => 2 // num => 1
The operating principle inside the component is not open to users.
It is easy to understand that the component should be a black box and users need not pay attention to the internal implementation principle. Of course, components should ensure high stability and reliability.
The input and output of the component are completely determined.
Combining the concepts of “pure function” and “black box”, a component should be predictable, and only fully determined input and output can be guaranteed. Therefore, in engineering practice, it is very necessary to enforce the input data type and variable name.
There are still many best practices for component development, such as “business components” that cover certain logical functions are also worth discussing. This article is only a few personal insights during the development. I hope you can share with me. Thank you for reading.