I finally finished reading "big talk Design Model" and received the book from. At that time, I was still in the digital building of shuangan. Now the company has moved to pangu. in a twinkling of an eye, it has been a year.
Taking advantage of this period of time, work is relatively idle, two weeks, read more than half, that is, from the purchase of books for a large period of time, is paused. In fact, the example of the calculator at the beginning gave me a great shock. Combined with my work over the past year, it was finally a step towards the object-oriented door.
If the code is well designed, you can add fewer classes.
In "Yi Tian tu long Kee", Zhang Wuji learned Taijiquan. After three times, he forgot all his tricks. That is the highest level.
I think the learning of design patterns is also a truth. There is no need to make it happen. Use concepts and boxes to get stuck. What is the mode and what is the mode. It doesn't matter if you don't remember the name. You can even change the implementation of the Classic mode. Your purpose is to make the code more elegant and easier to maintain, or to let others know and use the mode yourself?
To learn the design model, we must master the following principles:
1. Single responsibility. Each class only implements one function, instead of combining too many functions in a class.
2. Open and closed principles. Open to add and close to modify. (You can add a function and repair it.
3. Dependency reversal principle. Dependent on abstraction (interface or parent class), rather than implementation (subclass)
4. module A is directly related to Module B. If Module B is directly related to Module C, and module A and Module C are not, module A calls Module C.
, Instead of calling B directly)
The following principles are summarized in my work:
1. Copying code is dangerous. If there are two identical sections of code, it can be said that there must be a problem, because each change requires the maintenance of the two sections of code
2. Reduce IO operations as much as possible, such as database operations, network transmission, and even printf. These operations are much slower than direct memory operations,
3. When modifying a Bug, you must check the Bug from the simplest basic point. Do not check the lowest level. It is found that the input parameter is incorrect. Do not doubt the system part.
4. design the architecture and learn details
5. Some bugs may take a long time and effort to tune up, or even take two or three days. In fact, when writing at that time, you only need to pay attention to them and you can easily avoid them. Avoiding the cost of bugs is too much lower than finding and modifying bugs.
6. Divide a long piece of code into many small functions for easy maintenance, and there are hundreds of problems with codes that you don't want to read or modify.
7. When writing a program, first clarify the process. Write down the functions used in each process clearly, and leave the functions blank. In this way, programming becomes an empty question.
8. design the data structure when creating new functions.
9. The more empty the subject, the more flexible the code.
Some people do not like the book "big talk Design Patterns" and think it is too low-end. They like reading "high-end" books or even original English versions. Some people do not like the design model. They think it is all nonsense and useless.
I responded to them in one sentence. Whether it's a black cat or a white cat, catching a mouse is a good cat.