Ruby Object Oriented thinking concept _ruby topic

Object-orientedis a very confusing language. It's all about being object-oriented and making people think you're trendy. Ruby claims to be an object-oriented scripting language, but what is "object-oriented"? We've got all kinds of answers, but all of this is probably due to the same thing. Rather than summarizing it quickly, let's take a moment to think about the traditional programming paradigm. Traditionally, a programming problem begins with a variety of data that emerges, as well as processes that process data (procedures). In this model, the data is inflexible, passive and useless; it completely turns to the large, active, logical, omnipotent process. The problem with this approach is that the program is written by programmers, and they can only jot down a handful of details at work. And as the project grows, its core is growing too hard to remember how the whole project works. Subtle errors and knock errors are becoming more and more likely to cause bugs bugs. Complex and unexpected disturbances begin to appear in the core, maintenance also becomes like an attempt to catch an angry squid and not let its tentacles touch your face. Of course, there are a lot of ways to help you shrink and detect these bugs in traditional ways, but a better solution is to radically change the way we work. What the object-oriented does is let us give the actual, repetitive logic work to the data itself; it transforms our concept of data from passivity to initiative. Another way of saying this: We no longer let the data like an open box let us freely reach in and take out things. We look at it as a sealed machine with a switch and a dial. The interior of the "machine" mentioned above may be quite simple or complex; we can't peek outside and we can't allow ourselves to open the machine's shell (unless we do find it wrong), so we just need to flip the switch and read the scale to manipulate the data. Once the machine is built, we no longer have to think about how it works. You may feel that this is an unwarranted increase in your workload, but this approach will allow us to effectively prevent things from going in the wrong direction. Let's start with an example of a simple, worthless but at least part of the concept. Your car has a meter. Its job is to record the road from the last reset. How will we model the programming language? In C, the meter may be a numerical variable, presumably a float type. The program will increase its value by a certain number of strokes and reset to 0 at the appropriate time. Where is the problem? A bug in the program would assign a pseudo value to this variable for no reason. , which can be caused by unforeseen reasons. Anyone with experience in C programming will know that it will take hours or days to get rid of the bugs that are incredibly simple to find. (The moment you find it, you tend to pat your forehead hard.) The same problem starts with a very different perspective when using object-oriented objects. When you design it, the first thing the programmer will ask is not "what is the most similar data type?" But "what the hell is this thing?" This difference leads to a slightly difficult thing. We need to take a moment to determine what the meter is for and what the outside world wants to manipulate it. Then we decided to construct a small machine that allowed us to add, reset, and read the value, and nothing else. We do not provide a method for assigning arbitrary values to the meter: why? Because we all know that the meter does not work like that. You can only do that well-defined few things to the meter, and that's what we're allowed to do. So if something else in the program is wrongly assigned to it (for example, the temperature controller of the car), This immediately means that the error occurs. When running it (or when compiling, depending on the nature of the language) we're going to be accused of not assigning any value to the object of the meter. The message given may not be so clear, but it should be close to its true cause. It doesn't prevent the mistake from happening, does it? But it soon showed us directly the problem. This is just one of many ways that OO programming will save us a lot of time. In general, we will consider abstracting the above, because it is much simpler to build a factory to build a machine than to build it individually. We do not want to directly create a separate meter; In other words, we want all the meters to be made out of a model. This pattern (if you like, call it a meter factory) corresponds to what we call a class, each of which is generated by a separate meter (or made by a factory). Corresponds to an object. Many object-oriented languages require that we define their classes before owning a new object, but Ruby is not. Of course, the use of the object language does not mean that there will be a good face object design. In fact, in any language there is writing vague, careless, worm, low attainments and unstable code. Ruby can do for you (as a counter example, especially C + +) is the practice of OO programming is natural enough that even if you use it on a small scale you don't feel the need to rely on ugly code to improve efficiency. We will discuss with this handbook the mechanism of Ruby to achieve these predetermined goals; the next chapter will be " Switch and scale list (object method), and then we'll talk about "factory" (Class). Will you come with us?