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

Мы уже говорили о методах модуля, а как насчет методов экземпляра? Модуль — это не класс, у него не может быть экземпляров, а к методу экземпляра нельзя обратиться, не указав вызывающий объект.

Но оказывается, модуль может иметь методы экземпляра. Они становятся частью класса, который включил модуль директивой include.

module MyMod

 def meth1

  puts "Это метод 1."

 end

end

class MyClass

 include MyMod

 # ...

end

x = MyClass.new

x.meth1 # Это метод 1.

Здесь модуль MyMod подмешан к классу MyClass, а метод экземпляра meth1 унаследован. Вы видели также, как директива include употребляется на верхнем уровне программы; в таком случае модуль подмешивается к классу Object.

А что происходит с методами модуля, если таковые определены? Если вы думаете, что они становятся методами класса, то ошибаетесь. Методы модуля не подмешиваются.

Но если такое поведение желательно, то его можно реализовать с помощью нехитрого трюка. Существует метод append_features, который можно переопределить. Он вызывается с параметром — «целевым» классом или модулем (в который включается данный модуль). Пример приведен в листинге 11.6.

Листинг 11.6. Включение модуля с переопределенным методом append_features

module MyMod

 def MyMod.append_features(someClass)

  def someClass.modmeth

   puts "Метод модуля (класса) "

  end

  super # Этот вызов обязателен!

 end

 def meth1

  puts "Метод 1"

 end

end

class MyClass

 include MyMod

 def MyClass.classmeth

  puts "Метод класса"

 end

 def meth2

  puts "Метод 2"

 end

end

x = MyClass.new

# Выводится:

MyClass.classmeth # Метод класса

x.meth1           # Метод 1

MyClass.modmeth   # Метод модуля (класса)

x.meth2           # Метод 2

Этот пример заслуживает детального рассмотрения. Во-первых, надо понимать, что метод append_features не просто вызывается в ходе выполнения include; на самом деле именно он и несет ответственность за включение. Поэтому-то вызов super необходим, без него оставшаяся часть модуля (в данном случае метод meth1) вообще не была бы включена.

Отметим также, что внутри тела append_features имеется определение метода. Выглядит это необычно, но работает, поскольку вложенное определение порождает синглетный метод (уровня класса или модуля). Попытка определить таким образом метод экземпляра привела бы к ошибке Nested method error (Ошибка при определении вложенного метода).

Модуль мог бы захотеть узнать, кто был инициатором примеси. Для этого тоже можно воспользоваться методом append_features, потому что класс-инициатор передается ему в качестве параметра.

Можно также подмешивать методы экземпляра модуля как методы класса. В листинге 11.7 приведен соответствующий пример.

Листинг 11.7. Методы экземпляра модуля становятся методами класса

module MyMod

 def meth3

  puts "Метод экземпляра модуля meth3"

  puts "может стать методом класса."

 end

end

class MyClass

 class << self # Здесь self - это MyClass.

  include MyMod

 end

end

MyClass.meth3

# Выводится:

# Метод экземпляра модуля meth3

# может стать методом класса.

Здесь полезен метод extend. Тогда пример можно записать так:

class MyClass

 extend MyMod

end

Мы все время говорим о методах. А как насчет переменных экземпляра? Конечно, модуль может иметь собственные данные экземпляра, но обычно так не делают. Впрочем, если вы решили, что без этого никак не обойтись, ничто вас не остановит.

Можно подмешивать модуль к объекту, а не классу (например, методом extend), см. по этому поводу раздел 11.2.2.

Важно понимать еще одну вещь. В вашем классе можно определить методы, которые будут вызываться из примеси. Это удивительно мощный прием, знакомый тем, кто пользовался интерфейсами в Java.

Классический пример, с которым мы уже сталкивались ранее, — подмешивание модуля Comparable и определение метода <=>. Поскольку подмешанные методы могут вызывать метод сравнения, то мы получаем операторы <, >, <= и т.д.

Другой пример — подмешивание модуля Enumerable и определение метода <=> и итератора each. Тем самым мы получаем целый ряд полезных методов: collect, sort, min, max и select.

Можно также определять и собственные модули, ведущие себя подобным образом. Возможности ограничены только вашим воображением.

11.1.13. Трансформация или преобразование объектов

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

Каждый объект можно тем или иным способом представить в виде строки. Но не каждый объект может успешно «прикинуться» строкой. Именно в этом и состоит различие между методами to_s и to_str. Рассмотрим этот вопрос подробнее.

При использовании метода puts или интерполяции в строку (в контексте #{...}) ожидается, что в качестве параметра будет передан объект string. Если это не так, объект просят преобразовать себя в string, посылая ему сообщение to_s. Именно здесь вы можете определить, как объект следует отобразить; просто реализуйте метод to_s в своем классе так, чтобы он возвращал подходящую строку.

class Pet

 def initialize(name)

  @name = name

 end

 # ...

 def to_s

  "Pet: #@name"

 end

end

Другие методы (например, оператор конкатенации строк +) не так требовательны, они ожидают получить нечто достаточно близкое к объекту string. В этом случае Мац решил, что интерпретатор не будет вызывать метод to_s для преобразования нестроковых аргументов, поскольку это могло бы привести к большому числу ошибок. Вместо этого вызывается более строгий метод to_str. Из всех встроенных классов только String и Exception реализуют to_str, и лишь String, Regexp и Marshal вызывают его. Увидев сообщение TypeError: Failed to convert xyz into string, можно смело сказать, что интерпретатор пытался вызвать to_str и потерпел неудачу.

Вы можете реализовать метод to_str и самостоятельно, например, если хотите, чтобы строку можно было конкатенировать с числом:

class Numeric

 def to_str

  to_s

 end

end

label = "Число " + 9 # "Число 9"

Аналогично обстоит дело и в отношении массивов. Для преобразования объекта в массив служит метод to_a, а метод to_ary вызывается, когда ожидается массив и ничего другого, например в случае множественного присваивания. Допустим, есть предложение такого вида:

а, b, с = x

Если x — массив из трех элементов, оно будет работать ожидаемым образом. Но если это не массив, интерпретатор попытается вызвать метод to_ary для преобразования в массив. В принципе это может быть даже синглетный метод (принадлежащий конкретному объекту). На само преобразование не налагается никаких ограничений, ниже приведен пример (нереалистичный), когда строка преобразуется в массив строк:

class String

 def to_ary

  return self.split("")

 end

end

str = "UFO"

a, b, с = str # ["U", "F", "O"]

Метод inspect реализует другое соглашение. Отладчики, утилиты типа irb и метод отладочной печати p вызывают inspect, чтобы преобразовать объект к виду, пригодному для вывода на печать. Если вы хотите, чтобы во время отладки объект раскрывал свое внутреннее устройство, переопределите inspect.

Есть и еще одна ситуация, когда желательно выполнять такие преобразования «за кулисами». Пользователь языка ожидает, что Fixnum можно прибавить к Float, а комплексное число Complex разделить на рациональное. Но для проектировщика языка это проблема. Если метод + класса Fixnum получает аргумент типа Float, то что он должен с ним делать? Он знает лишь, как складывать значения типа Fixnum. Для решения проблемы в Ruby реализован механизм приведения типов coerce.