Ruby Object-oriented thinking concept

Object-orientedIt is a confusing wording. object orientation makes others think you are fashionable. ruby claims to be an object-oriented scripting language, but what exactly is "Object-Oriented "? We already have a variety of answers, but all these are probably attributed to the same thing. Rather than quickly summarizing it, let's take a moment to think about the traditional programming model. Traditionally, a programming problem begins with various data and procedures. in this mode, data is rigid, passive, and useless. It completely appeals to the large, active, logical, and omnipotent process body. The problem with this practice is that the program is written by programmers who can only remember a few details at work. as the project grows, its core also increases to hard to remember how the entire project works. subtle mistakes and hitting errors become more and more prone to hard-to-find bugs (bugs ). complex and unexpected interference began to appear in the core, and maintenance became like an attempt to catch an angry squid and not let it touch your face. of course, for traditional methods, we also have many ways to guide you to narrow down and detect these bugs, but a better solution is to completely change the way we work. What object-oriented means is to let us hand over practical and repetitive logical work to the data itself; it changes our concept of data from passive to active. Another saying is: We don't want data to be as open as a box. We regard it as a sealed machine with a switch and dial. The "machine" mentioned above may be quite simple or complex. We cannot peat from the outside, nor allow ourselves to open the Machine Shell (unless we do find it wrong ), therefore, we only need to read the scale to operate the data through the switch. once a machine is built, we no longer have to consider how it works. Maybe, you may think this is adding your own workload for no reason, but this method can help us effectively avoid things going bad. Let's start with a simple example with no practical value but at least some concepts. Your car has a calculator. Its job is to record the road from the last reset. Cheng. How will we use programming languages for modeling? In C, the program may be a numerical variable, probably of the float type. this program will increase its value at a certain interval and reset it to zero when appropriate. where is the problem? A bug in the program will randomly assign a pseudo value to this variable, which may occur for some unexpected reasons. anyone with C programming experience will know that it will take several hours or days to get rid of this silly bug that is easy to find. (The moment I find it, I usually pat my forehead hard) The same problem starts from a different angle when using object-oriented programming. when designing it, the first thing programmers will ask is not "what is the data type most similar to it? "But" What exactly is this? "The difference leads to something that is a little difficult. we need to spend some time figuring out what the program is for and how the external world wants to manipulate it. then we decided to construct a small machine that allows us to add, reset, and read values. We do not provide a method for assigning any value to the program: Why? Because we all know that the pedometer does not work that way. you can only do the defined things to the pedometer, and the things that allow us to do. therefore, if something in the program is incorrectly assigned to it (for example, the car's Temperature Controller), this immediately means an error occurs. when running it (or when compiling, depending on the nature of the language), we will be accused of forbidding the program to assign any value to this object. the given message may not be so clear, but it should be close to its actual cause. this does not prevent errors, right? However, it quickly pointed out the problem. This is only one of the many methods that OO programming will save us a lot of time. In general, we will consider abstracting the above things, because building a factory to create machines is much simpler than creating one by one. We do not want to directly create a separate calculator; In other words, we hope that all the schedulers can be created by one model. this mode (if you like it, it is called the program factory) corresponds to a class we call, and each independent program generated by it (or created by the factory) corresponds to an object. many object-oriented languages require us to define its class before we have a new object, but Ruby is not like this. Of course, the use of object-oriented language does not mean that there will be good object-oriented design. in fact, you can use any language to write fuzzy, careless, multi-worm, low-profile, and unstable code. what Ruby can do for you (as an inverse example, especially C ++) is to make OO programming practices natural enough, even if you only use it in a small scope, you do not feel that you must rely on Ugly code to improve efficiency. we will go into depth with this manual to discuss Ruby's mechanisms for achieving these goals; the next chapter will be "switch and dial tables" (Object methods ), then we will discuss "factory" (class ). will you come with us?