Analyze rudy Access Control

Previously, we mentioned that Ruby has no functions, but only methods. There are actually more than one method. In this section, we will introduce access control (access controls ).

Think about what happens when we define a method in the "highest level" rather than in the definition of a class. we can imagine this method as a function in a traditional language like C.

Ruby> def square (n)
| N * n
| End
Nil
Ruby> square (5)
25


Our new method does not seem to belong to any class, but Ruby actually assigns it to the Object class, that is, the parent class of all other classes. therefore, all objects can now use this method. this should be correct, but there is a small trap: it is the private (private) method of all classes. we will discuss what this means below, but one result is that it can only be called in the function style, like this:

Ruby> class Foo
| Def fourth_power_of (x)
| Square (x) * square (x)
| End
| End
Nil
Ruby> Foo. new. fourth_power_of 10
10000


We do not allow explicit use of this method to an object:

Ruby> "fish". square (5)
ERR: (eval): 1: private method 'square 'called for "fish": String


This clever approach enables ruby to provide functions that can be used in traditional languages while maintaining ruby's pure OO nature (functions are still object methods, but the receiver is implicitly self ).

In OO programming, there is an unwritten habit, which we have hinted at in the previous chapter, that is, the difference between specification and implementation, or what task the object is required to complete and how it is actually completed. the internal work of an object should be invisible to users. They should only care about the input and output, and believe that the object knows what it is doing internally. in this way, some methods that are invisible to the outside world but used internally (and can be improved by the programmer at any time of need without changing the object of the class seen by the user) will be very useful. in the following general example, you can regard engine as an internal implicit method of the class.

Ruby> class Test
| Def times_two ()
| Print a, "times two is", engine (a), "\ n"
| End
| Def engine (B)
| B * 2
| End
| Private: engine # this hides engine from users
| End
Test
Ruby> test = Test. new
# <Test: 0x4017181c>
Ruby> test. engine (6)
ERR: (eval): 1: private method 'engine' called for # <Test: 0x4017181c>
Ruby> test. times_two (6)
6 times two is 12.
Nil


At the beginning, we wanted test. engine (6) returns 12, but when we assume a Test object user, we learned that engine is inaccessible (inaccessible ). only other methods of Test can be used, such as times_two. we are required to maintain the program's external interfaces, that is, the times_two methods. programmers who manage this class can freely change the engine (here, B * 2 may be changed to B + B, assuming this can improve performance) without affecting the user's dealings with the Test object. this example is too simple. The advantages of access control can only be shown when we start to write more complex and interesting classes.