The programming world has changed dramatically over the past 25 years. Today, we have a large number of useful and flexible data types to use, but 25 years ago, you need to spend a lot of extra time constructing these types on your own.
C and PASCAL languages-the standard language at that time-provide a small number of machine-oriented data types: Numbers, pointers, arrays, and formal strings, and a structure or record that combines multiple types of data. It is important that, based on these basic types, we can construct more interesting types, such as stacks, trees, chain tables, hash tables, and variable arrays.
In Perl, Python, or Erlang, I don't need to consider these things. When using list, string, or array, I don't care how many elements they can hold or where they are stored. Dictionary is the most commonly used. Similarly, there is no need to worry about how its capacity or hash conflicts avoid details.
In addition, I still need some new data types, but they are more of a transformation of the existing type, rather than restructuring. The vector of any dimension is actually an array. An RGB color value is actually a 3 RMB tuple. A Polynomial can be either a tuple or a list. I was surprised that these data types, such as array, tuple, list, and dictionary, have greatly eliminated the inconvenience in the Basic Data Types I learned in college courses. When achieving a balanced binary tree, you focus on how to balance the binary tree, rather than struggling with messy pointer operations.
Building an existing small square into a new building will lead to greater changes than the appearance of small blocks. How these small blocks appear is no longer the focus of attention. In many programming courses and teaching materials, a batch of new words suddenly emerged in the good teaching: objects, constructors, abstract basic classes, and private methods. Therefore, in the next job, the RGB color value expressed by a simple ternary tuple is replaced by a class with a get or set method and a high-level constructor, A large numberCode.
This is why some people keep calling for it, explaining why object-oriented is not a good thing, and making programming less fun. But it rarely works.
it is not object-oriented or has any defects. But object-oriented is not the basic atom of computer programming, they do not exist naturally as people imagine. Using object-oriented to solve the problem without a threshold will make the code bloated and over-Technical. However, many people insist on persistently using objects to solve all the problems. This is terrible because it makes it difficult for people to identify whether the object-oriented style has actually produced results that simplify the problem and are easy to understand.