Copy and paste is the enemy of packaging

Before talking about OO, design patterns, and the many object-oriented principles, we should first master one thing: encapsulation. After mastering the principles and techniques of encapsulation, you can construct a program with a beautiful framework even if you are not using an OO language. Applying these principles outside of programs can also produce surprising results. "Design Rules - The Power of Modularity" (http://www.douban.com/subject/1737636/) places encapsulation and modularity on a pedestal, and they deserve this position. This is the most basic way (no other) we use to solve complexity problems.

A program is a complex system. "Tao begets one, one begets two, two begets three, three begets (four, four begets...) all things." If the source of complexity is regarded as the transformation of "Tao", then this "one" must be encapsulation. Different programming languages and the methods derived from these programming languages are in the "second" position, such as the OO design paradigm, the FP (functional programming) paradigm, the principle of layering, and so on. OO design principles, such as the Liskov Substitution Principle and composition taking precedence over inheritance, are in the "third" position, while specific design patterns and the like are in the "fourth" position after the "third".

I am stupid and still can't remember those principles, such as what is the Liskov Substitution Principle and how to implement this model or that model. Among the design patterns, I am only interested in the strategy pattern and have little interest in other patterns. In essence, these patterns or principles only provide us with a method and a tool to better implement encapsulation.

Copy and paste is the enemy of encapsulation and the biggest smell of ugly code. Copying once is equivalent to adding at least one variable point, and copying twice is equivalent to adding at least two variable points. Why do we say "at least"? Because there are associations between modules, changes in one place will cause changes in multiple other places as well. If we assume that S is the system itself, M is a measurement of the system itself, and C is the average number of copies of the module in system S (C>1), then the relationship between M and C should be an exponential relationship: M is proportional to C to the power of N (N>1).

The exponential relationship is already scary enough, but what’s even scarier is that when a module in the system changes, if the module has multiple copies in the system, we may be lazy and only change one of the copies instead of modifying all of them. This will lead to the splitting of the module, from one module to several similar but different modules, greatly increasing the complexity of the system and ultimately causing the system to rot. Intuitively, the complexity of a poorly designed system is roughly a factorial relationship or even a power relationship of the number of modules, which is a more terrifying relationship than an exponential relationship.

So, copying and pasting is a very evil way of coding. When coding, you need to find ways to reduce copying and pasting. This is something that should be considered during coding, rather than something to be done during the refactoring phase. As for what method, means and model to use, these are all matters of detail.

If you insist on not copying and pasting, and stick to it, the benefits will be huge, and the code you write will be of high quality and high value. When I see other people’s systems, I can immediately tell what the advantages and disadvantages of this system are. Be it design patterns, orthogonality of interfaces, or design principles, maybe you have never deliberately studied them, but in the end you will find that they all lead to the same destination, and you have a sense of connection with the foreign experts. We will spontaneously combine and improve the ideas and methods of these experts, and even create new methods and means. Start directly from one, one gives rise to two, two gives rise to three gives rise to four, rather than learning the three and the four in a dogmatic and worshipful manner. Maybe at that time, you have forgotten what an object is.

The reason I'm complaining is that from yesterday to today, I'm refactoring a module. The core component of this module M1 is a layout rule editor wrapped from RTF. The guy who designed this core component designed a control A with RichTextBox as the center, and then extracted some rule logic of this control and put it in the static methods of class B and class C. What's more amazing is that class B is in another module M2, while class C is in module M1. This control is used in three places in M1: D, E, and F. Each of D, E, and F must register seven or eight events for this space A, and then call the static method of class B in module M2 and the static method of class C in module M1 in the event callback function to implement some logic. Now, I want to write a control G, and this G also needs control A. In this case, I must register a bunch of A's events and callback functions for G, and then put a bunch of logic in the callback function, which will take at least 200 lines of code. In order to write these callback functions, I must understand the internal operating mechanisms of control A and classes B and C. In other words, in order to eat pork, you have to kill the pig yourself. Of course, you can also copy the code from D, E or F and modify it to save time.

The serious problem is that control A itself has logical errors and imperfect functions, and it needs to be repaired. Because it replicates everywhere, one move will affect the whole body. If you perform surgery on A, you must also perform surgery on B, C, D, E, and F. When performing surgery on A, in order to get it compiled, I commented out all the codes related to A in B, C, D, E, and F, commenting out about 1,500 lines of code in total. In fact, there are only about 200 lines of truly valuable code in these 1500 lines of code, and the rest of the code is all completed by copying, pasting, and changing the variable name.

Why does this problem occur? Because of copy and paste. Copying and pasting is easy. You can just copy and change a few words and use it without having to spend time thinking about the packaging. The actual situation is that to reference the control A, you have to write 200-300 lines of code. If you reference it in multiple places, you have to write more than 1,000 lines of code. Copying and pasting is not troublesome, but if you find that there is an error in A, or it needs to be expanded, when you change A, you also have to move these 1,000 lines of code. These 1,000 lines of code may involve more code, which will eventually lead to the need to modify more code. This is code rot.

In fact, this A is very well encapsulated. It does not require other classes to input any input data to it. Other classes only need to obtain a final rule result, a List, from the A control. If the encapsulation is good, calling A and getting the result can be achieved with two or three lines of code.

The reason for not encapsulating is because we are used to copying and pasting, or we are too lazy to encapsulate, or we don’t have the idea of encapsulating at all.

Many new or not-so-new programmers, especially Web development programmers, always complain about the low technical content of their work and always want to learn more. In essence, the work they do is very technical, it all depends on how you look at it.

If you only regard your work as simple copying, pasting, plagiarism, and code modification, the technical content will naturally be low. If you view your job as how to eliminate copying and pasting, how to improve quality and progress, eliminate unnecessary things in work, and eliminate all kinds of waste, then the technical content of this job is extremely high. Don't worship the master. When you do that, you are doing the master's work. Don't worship new technology. When you do, your job may be the embryo of a new generation of technology. Every bit, every color and every fragrance, it’s all in my heart. The green bamboos are all Dharmakaya, and the lush yellow flowers are all Prajna.

<<: MySql development of automatic synchronization table structure

>>: Development details of Vue3 components

Detailed tutorial on replacing mysql8.0.17 in windows10

Copy and paste is the enemy of packaging

Detailed tutorial on replacing mysql8.0.17 in windows10

MySQL uses variables to implement various sorting

Super detailed tutorial to implement Vue bottom navigation bar TabBar

Use nginx to dynamically convert image sizes to generate thumbnails

Detailed explanation of eight methods to achieve CSS page bottom fixed

Analysis and solution of abnormal problem of loading jar in tomcat

Summary of pitfalls in virtualbox centos7 nat+host-only networking

Summary of the differences between get and post requests in Vue

Some indicators of excellent web front-end design

The most complete package.json analysis

Recommend

Detailed explanation of Angular data binding and its implementation

Solution to the problem that the number of MySQL connections is limited to 214 in CentOS 7

Using react+redux to implement counter function and problems encountered

Detailed explanation of lazy loading and preloading of webpack

Docker container introduction

Vue batch update dom implementation steps

js implements a simple method of encapsulating jQuery and a detailed explanation of chain operations

Detailed explanation of MySQL transaction processing usage and example code

How to implement a password strength detector in react

Vue uses rules to implement form field validation

How to use the debouce anti-shake function in Vue

CSS to achieve particle dynamic button effect

HTML iframe usage summary collection

Win10+Ubuntu 20.04 LTS dual system installation (UEFI + GPT) (pictures and text, multiple pictures warning)

What you need to know about msyql transaction isolation