Interface reflection delegated Design Mode

The two blogs that are frequently followed in the blog community have written code for five years without understanding interfaces, reflection, delegation, and design patterns, as well as vernacular reflection, lao Zhao wrote an article about vernacular reflection. I also felt that the interface reflected these things, no matter which programming language belongs to the "xxx advanced programming" and so on. The ability to use these things flexibly and without excessive use naturally belongs to the ranks of programmers.

I also learned a little programming syntax in the C language course in college and started to work as a programmer by myself. At the beginning, I never thought that these things would be difficult. Everything should be done right away, and the ship will naturally go straight to the bridgehead. People think of three-dimensional development when traffic is crowded; Class differentiation leads to social instability when people think of creating a country. As things develop to a certain extent, new things will emerge. The programming language is no exception. From machine code to advanced language, from process to object, until the concept of interface reflection delegate appears, these are the needs of software development. When we learn a concept that is hard to understand in programming, If we carefully consider it and find out where it facilitates development and improves efficiency, we will be able to grasp it quickly. If you can't think of the reason, it means that your own foundation and practices are not enough.

Learning and learning are for learning. It doesn't matter if you just encapsulate a piece of code that is used in multiple places into a function and cannot understand the usefulness of the class. Use your functions to implement various programs. Most operating systems are written in C without the concept of classes. After writing about several hundred functions, you will remember that some related functions seem to be associated with one thing called a class. Then, let's review the concept of the class. after a long time of debugging and exploration, you have implemented your ideas. OK, you have changed your mind, and the realm has been sublimated.

When I used reflection for the first time last year, I also wrote a lot of entity classes and felt that the conversion between attributes and SQL queries, result sets, and attributes was repeated, I thought it might seem like there was something called reflection, and it saved a lot of code and time. Although it will soon be known that the performance of the reflected read object attributes is not good and should be avoided in large quantities, reflection is always an entry.

The purpose of learning is not to get familiar with everything. Although the brain capacity is unfathomable, the speed of receiving new things is limited. Some things need to be mastered, some things only need to be remembered, or even leave a register in your mind. There is a famous law of 20-80, which is very suitable for programming and learning.

I think the old idea of saying "interface doesn't understand, don't worry about reflection" is purely nonsense. Do these two concepts need to be linked? However, the "Vernacular" in his questions makes sense, because from small to large, from school to society, we have learned almost all the black words, and we need more vernacular. The vernacular is guided education, while the black talk is cramming education. The deep-rooted influence of education from the parent to the teacher to the author of books is full of education. In at least a few programming and development books I have read, when introducing concepts obscure to beginners, I cannot find any attempt on the book pages to help readers understand its meaning. We are used to the thinking of being filled with ducks. for software development, such a discipline that requires repeated learning, practice, understanding, and practice, many beginners are confused and give up because of their steps. This is really a tragedy!

Let us free ourselves from our thoughts, concentrate the journey of the generations of the software industry in our golden years, and seize the opportunity. Stick to your dreams, lead the next software revolution, and create a master who is more advanced than interfaces, reflection, and delegation. Maybe you are the master of things!