Ранее мы говорили, что в Ruby нет функций, только методы Тем не менее, есть более чем один вид методов. Earlier, we said that ruby has no functions, only methods. However there is more than one kind of method. В этой главе мы введем понятие управления доступом.
Посмотрим, что случится, если мы определим метод "top level", а не внутри определения некоторого класса. Можно представить данный метод аналогом функции в более традиционном языке программирования, таком как С.
ruby> def square(n)
| n * n
| end
nil
ruby> square(5)
25
Кажется, что наш метод не принадлежит никакому классу, однако Ruby включает его в определение базового класса Object, который является суперклассом для любого другого класса. В результате любой объект в состоянии использовать данный метод. Все правильно, но есть некоторый подвох: это private (приватный) метод для любого класса. Ниже мы рассмотрим, что это означает, но одним из следствий является то, что он может быть вызван только как функция, как в примере:
ruby> class Foo
| def fourth_power_of (x)
| square(x) * square(x)
| end
| end
nil
ruby> Foo.new.fourth_power_of 10
10000
Мы не можем явно применить метод к объекту:
ruby> "fish".square(5)
ERR: (eval):1: private method `square′ called for "fish":String
Это достаточно разумно для сохранения чистой ОО природы Ruby (функции - это все еще методы объектов, но получателем вызовов явно является self) при обеспечении возможности вызова функций, написанных на традиционных языках программирования.
Общепринятым подходом в ОО программирование, как мы обращали внимание ранее, является разделение спецификации и реализации, или что метод объекта должен выполнять и как он на внутри это делает. Внутренне поведение объекта в общем случае должно быть скрыто от его пользователей; их должно волновать лишь что они передают и что получают обратно, надеясь, что объект знает, как что делать внутри. Как таковое, часто бывает полезно иметь в классах методы, невидимые снаружи, но которые используются внутри (и могут быть изменены программистом при необходимости, без влияния на видение объектов данного класса конечными пользователями). В приведенном ниже тривиальном примере смотрите на engine как на невидимого внутреннего работягу.
ruby> class Test
| def times_two(a)
| 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
Можно предположить, что test.engine(6) вернет значение 12, но, как мы знаем, engine недоступен пользователю объекта Test. только другие методы Test, такие как times_two, имеют право использовать engine. Нам необходимо использовать общедоступный интерфейс, который состоит из метода times_two. Программист, который разрабатывает этот класс, может свободно изменить engine (здесь, например, написав вместо b*2 строку b+b, предполагая большую производительность нового варианта) не воздействуя на взаимодействие пользователя с объектами класса Test objects. Безусловно, данный пример слишком прост чтобы быть полезным; преимущества управления доступом становятся яснее только когда мы начинаем создавать более сложные и интересные классы.
Источник: www.opennet.ru
К началу статьи
