Хэл Фултон - Программирование на языке Ruby

require 'delegate'

class MyQueue < DelegateClass(Array)

def initialize(arg=[])

super(arg)

end

alias_method :enqueue, :push

alias_method :dequeue, :shift

end

mq = MyQueue.new

mq.enqueue(123)

mq.enqueue(234)

p mq.dequeue # 123

p mq.dequeue # 234

Можно также унаследовать класс Delegatorи реализовать метод __getobj__; именно таким образом реализован класс SimpleDelegator. При этом мы получаем больший контроль над делегированием.

Но если вам необходим больший контроль, то, вероятно, вы все равно осуществляете делегирование на уровне отдельных методов, а не класса в целом. Тогда лучше воспользоваться библиотекой forwardable. Вернемся к примеру очереди:

require 'forwardable'

class MyQueue

extend Forwardable

def initialize(obj=[])

@queue = obj # Делегировать этому объекту.

end

def_delegator :@queue, :push, :enqueue

def_delegator :@queue, :shift, :dequeue

def_delegators :@queue, :clear, :empty?, :length, :size, :<<

# Прочий код...

end

Как видно из этого примера, метод def_delegatorассоциирует вызов метода (скажем, enqueue) с объектом-делегатом @queueи одним из методов этого объекта ( push). Иными словами, когда мы вызываем метод enqueueдля объекта MyQueue, производится делегирование методу push объекта @queue(который обычно является массивом).

Обратите внимание, мы пишем :@queue, а не :queueили @queue. Объясняется это тем, как написан класс Forwardable; можно было бы сделать и по-другому.

Иногда нужно делегировать методы одного объекта одноименным методам другого объекта. Метод def_delegatorsпозволяет задать произвольное число таких методов. Например, в примере выше показано, что вызов метода lengthобъекта MyQueueприводит к вызову метода lengthобъекта @queue.

В отличие от первого примера, остальные методы делегирующим объектом просто не поддерживаются. Иногда это хорошо, ведь не хотите же вы вызывать метод []или []=для очереди; если вы так поступаете, то очередь перестает быть очередью.

Отметим еще, что показанный выше код позволяет вызывающей программе передавать объект конструктору (для использования в качестве объекта-делегата). В полном соответствии с духом «утилизации» это означает, что я могу выбирать вид объекта, которому делегируется управление, коль скоро он поддерживает те методы, которые вызываются в программе.

Например, все приведенные ниже вызовы допустимы. (В последних двух предполагается, что предварительно было выполнено предложение require 'thread'.)

q1 = MyQueue.new # Используется любой массив.

q2 = MyQueue.new(my_array) # Используется конкретный массив.

q3 = MyQueue.new(Queue.new) # Используется Queue (thread.rb).

q4 = MyQueue.new(SizedQueue.new) # Используется SizedQueue (thread.rb).

Так, объекты q3и q4волшебным образом становятся безопасными относительно потоков, поскольку делегируют управление безопасному в этом отношении объекту (если, конечно, какой-нибудь не показанный здесь код не нарушит эту гарантию).

Существует также класс SingleForwardable, который воздействует на один экземпляр, а не на класс в целом. Это полезно, если вы хотите, чтобы какой-то конкретный объект делегировал управление другому объекту, а все остальные объекты того же класса так не поступали.

Быть может, вы задумались о том, что лучше — делегирование или наследование. Но это неправильный вопрос. В некоторых ситуациях делегирование оказывается более подходящим решением. Предположим, к примеру, что имеется класс, у которого уже есть родитель. Унаследовать еще от одного родителя мы не можем (в Ruby множественное наследование запрещено), но делегирование в той или иной форме вполне допустимо.

Мы уже рассматривали методы attr_reader, attr_writerи attr_accessor, которые немного упрощают определение методов чтения и установки атрибутов экземпляра. А как быть с атрибутами уровня класса?

В Ruby нет аналогичных средств для их автоматического создания. Но можно написать нечто подобное самостоятельно.

В первом издании этой книги была показана хитроумная схема на основе метода class_eval. С ее помощью мы создали такие методы, как cattr_readerи cattr_writer.

Но есть более простой путь. Откроем синглетный класс и воспользуемся в нем семейством методов attr. Получающиеся переменные экземпляра для синглетного класса станут переменными экземпляра класса. Часто это оказывается лучше, чем переменные класса, поскольку они принадлежат данному и только данному классу, не распространяясь вверх и вниз по иерархии наследования.

class MyClass

@alpha = 123 # Инициализировать @alpha.

class << self

attr_reader :alpha # MyClass.alpha()

attr_writer :beta # MyClass.beta=()

attr_accessor :gamma # MyClass.gamma() и

end # MyClass.gamma=()

def MyClass.look

puts " #@alpha, #@beta, #@gamma"

end

#...

end

puts MyClass.alpha # 123

MyClass.beta = 456

MyClass.gamma = 789

puts MyClass.gamma # 789

MyClass.look # 123, 456, 789

Как правило, класс без переменных экземпляра бесполезен. Но здесь мы их для краткости опустили.

В различных кругах популярны разные философии программирования. Часто их трудно охарактеризовать с точки зрения объектной ориентированности или динамичности, а некоторые вообще не зависят от того, является ли язык динамическим или объектно-ориентированным.

Поскольку мы отнюдь не эксперты в этих вопросах, будем полагаться в основном на чужие слова. Так что воспринимайте то, что написано ниже, с некоторой долей скепсиса.

Некоторые программисты предпочитают стиль ООП на основе прототипов (или ООП без классов). В этом мире объект не описывается как экземпляр класса, а строится с нуля. На базе такого прототипа могут создаваться другие объекты. В Ruby есть рудиментарная поддержка такого стиля программирования, поскольку допускаются синглетные методы, имеющиеся только у отдельных объектов, а метод clone клонирует синглеты. Интересующийся читатель может также обратить внимание на простой класс OpenStructдля построения объектов в духе языка Python; не забывайте также о том, как работает метод method_missing.

Парочка ограничений в Ruby препятствует реализации ООП без классов. Некоторые объекты, например Fixnum, хранятся как непосредственные значения, а не ссылки, поэтому не могут иметь синглетных методов. В будущем ситуация, вероятно, изменится, но пока невозможно предсказать, когда это произойдет.