Can you write a dazzling array of codes to show that you are a real master? Wrong, a real master has the most important programming thinking and technology. Even if all the technologies he knows now are outdated, he can still quickly master new technologies and write high-quality programs.
Today’s frameworks and popular languages encapsulate a large number of practical data structures and even some classic algorithms, which bring us great convenience. Using .NET to simply drag and drop a website, although Backend operations such as database binding, data processing, and data updating can be a bit repetitive and boring. Later, I came into contact with Linq and thinkPHP (php's MVC), which can greatly reduce these less technical codes. Even if I write too much, I still feel that it is not very interesting. It is not as enjoyable as writing a small program or game by yourself.
I remember that our data structure teacher once said: "Algorithm is an art." Then, almost the whole class responded with disdain, and I was one of its glorious members at that time. Therefore, I learned very badly about data structures and regretted it very much.
The algorithm book mentions Minesweeper, a classic game like Minesweeper. One of the core algorithms is to calculate how many mines are around each grid.
I think people who have been programming for two years will quickly think of such an algorithm: use a two-dimensional array to store the information of each grid (of course the mines have been allocated immediately), and then traverse the array, and count when one is traversed. The number of mines in the eight surrounding directions is saved in the currently traversed array item. Of course, the statistical process can be written as a function call. This is the easiest algorithm to think of.
Later I felt that this was a bit wasteful, because many grids without mines around them also had to scan eight directions to see if there were mines. I started to think about it, what I wanted to count was the number of mines around each grid, then What determines the number of mines? Of course they are mines, so I started to think of the second algorithm. I still traverse the two-dimensional array, but only when a mine is traversed, the values in the grid in the eight directions around the mine are +1. , which greatly reduces the number of statistics. This should be considered reverse thinking.
When Tongliang makes a chess program, he will encounter the "general" algorithm to determine whether his general or marshal is in a situation where he will be eaten in the next step (the terminology of chess is called general). Of course, the very simple algorithm is to traverse the opponent's currently existing and attacking chess pieces to determine whether it is possible to kill his general in the next step. But we can also think about it the other way around. Since we are judging whether the general is in a state of being killed, we start directly with him and judge whether there is an opponent, "pawn", "car" or "cannon" within his straight line range, and then judge the surroundings around us. Do you think there is a "horse" on the other side in the Japanese grid? Think about the problem in reverse.
The feeling of programming
The most important thing about programming is a kind of thought. The real joy of programming is to design an algorithm to give a program. Every program is alive, and the algorithm is their soul. Of course, creating a viable program is a happy thing. If you feel unhappy or programming is boring, it is because you are practicing some so-called technologies, so-called methods and patterns, rather than programming for the sake of programming.
Programming is inseparable from technology, just like martial arts training is inseparable from moves.
High-level warriors often say that the highest level of kung fu is when there is no move in the mind. And this kind of no-movement does not mean that you can't do anything, but that you have gathered the strengths of hundreds of schools of thought, and after integrating thousands of moves, your thoughts, moves, and body are highly unified, and you can use them as you like. It is not possible to achieve this state by learning all the moves. Only by truly knowing how to think about the inner connection between the moves and slowly integrating them into your own thoughts can you achieve this.
Some old programmers often teach us that the most taboo thing about programming is too much but not enough.
Knowing more does not mean you are a master, and knowing less does not mean you are a rookie. Programming focuses on thinking, and this kind of thinking determines how deeply you go in this technology.
What is thinking is the idea of solving problems, the ability to plan, the ability to analyze, and the ability to quickly organize the ideas for solving problems. It can be an algorithm, a pattern or a framework.
These ideas require several or more years of experience.
Object-oriented thinking is now popular. Let’s briefly talk about the superficial understanding of this idea since .NET. From the large number of function libraries in C to the large number of class libraries (or packages in Java) now, it seems that there are Once you learn classes, you become object-oriented. This statement is a bit far-fetched. Whether you learn Java or C++, the most important thing is to use C++ and Java to think about problems, use object-oriented to think about problems, and use objects as the primitives to deal with problems.
Last time I went for an interview, the interviewer asked me to talk about object-oriented inheritance, polymorphism, and encapsulation features.
I told him about a simple tank battle program I wrote that analyzes these three characteristics.
Inheritance: This concept is very easy to understand. The subclass inherits all the common members of the parent class, such as the base class of a tank, which implements basic tank characteristics and methods, such as size, health, movement, collision determination, etc., which will be discussed in the future. To design a unique tank, such as a phantom tank (Red Alert), you only need to inherit the parent class and add a phantom method to solve the problem. The advantages of inheritance are also obvious. Most of the characteristics and methods common to tanks are written into the base class. If you want to design a new type of tank in the future, you only need to inherit them, eliminating most of the code. So inheritance is the simplest and most practical.
Polymorphism: can be narrowly understood as the overloading of parent class methods, so that the same method has different parameter lists. I think polymorphism is the essence of object-oriented. In my tank program, there is a control rule class. There is a method in this class that requires a parameter. This parameter may be a tank class or a bullet class. I am not sure. , you need to call their move() method. Of course, you can use the powerful overloading function to overload this method, such as: someFun (tank mObj) {….}; Overload someFun (zidan mObj) {….}; It seems that except I changed the type of the mObj parameter, but nothing else was changed. But it did solve the problem. If the implementation of this abnormal method is 10,000 lines, one overload will have 20,000 lines. If the airplane class also has a move method in the future, it will have to be reloaded again. Using inheritance + interface is much simpler. You only need to write an interface called ImoveObj and define a move method in it. This interface is inherited by tanks, bullets, and aircraft classes. Write the method as someFun (ImoveObj mObj) {….}; later No matter how many classes are added that can serve as the mObj parameter, you only need to inherit the ImoveObj interface. (Those who have used the factory pattern feel that this is too common. Indeed, but this is also the basic understanding of polymorphism.)
Encapsulation: This is easy to understand. To use a class, you only need to know how to use the methods of this class. There is no need to know the specific implementation of this method. The interface is the developer's design specification, and the developer implements the things in the interface. Interfaces are also user instructions, telling users of a class what methods this class implements. As long as they can use them, they don't need to understand their implementation.
Although they are all simple basics, it will not be so difficult to study injection, inversion, mapping, etc. once you fully understand these things.
In addition to object-oriented, there are also interface-oriented, aspect-oriented (aspect), etc. No matter what ideas are used to program, the core is the algorithm. As small as a function, it is inseparable from the algorithm.
The most important thing in programming is thought, technology determines ability, and thought determines the depth of ability.