Что такое объект?

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

Плохо ли это, не знать, что там творится всередине? И да, и нет.

С другой стороны, если мы не знаем, что машина спроектирована не совсем гуд, и в процессе помола вибрирует настолько, что может свалиться со стола, то не сможем в этот момент придержать ее рукой. Быть в курсе таких тонкостей — ненормально. Но иногда это суровая необходимость, потому что не всегда можно выкинуть такой агрегат на свалку и купить в магазине адекватную модель.

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

Методы как задачи

Каждая задача, которую выполняет объект, оформляется в виде метода. Например, логично ожидать, что у нашего объекта-кофемашины есть как минимум один — make_coffee (сварить кофе).

Чем сложнее объект, тем больше у него задач, а значит — и методов. Но в правильно спроектированном объекте все задачи, независимо от количества, не выходят за рамки основного предназначения объекта. Если он начинает напоминать швейцарский нож, в котором есть вилка, шило, отвертка и открывашка, это тревожный звоночек, который говорит о необходимости перепоручения части функционала другому объекту.

Как методы появляются в объекте? Для этого в Ruby существует целых три возможности. Во-первых, объект получает методы от класса, который его создал.

Классы

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

class CoffeeMachine
  def make_coffee
    puts "Готовим воду и зёрна"
    puts "Варим и наливаем кофе"
  end
end

Вызов метода

Чтобы вызвать метод, Ruby необходима пара: объект и имя метода. Не бывает метода «просто так», у каждого есть хозяин.

Самый простой вызов метода выглядит так:

имя_объекта.название_метода

Объект перед вызовом должен существовать. Классы создаются в процессе своего объявления, экземпляры классов (преимущественно) — с помощью метода класса new.

:001 > class CoffeeMachine  # создаем объект-класс
:002?>   def make_coffee
:003?>     puts "Готовим воду и зёрна"
:004?>     puts "Варим и наливаем кофе"
:005?>   end
:006?> end
 => nil
:007 > saeco = CoffeeMachine.new  # создаем экземпляр класса (включаем конвейер)
 => #<CoffeeMachine:0x85dd718>
:008 > saeco.make_coffee
Готовим воду и зёрна
Варим и наливаем кофе
 => nil
:009 > CoffeeMachine.make_coffee
NoMethodError: undefined method 'make_coffee' for CoffeeMachine:Class

Текущий объект

Ruby разрешает вызывать методы без указания имени объекта, потому что постоянно отслеживает т. н. текущий объект (self). На место пропущенного объекта неявно подставляется self, чтобы сохранить пару:

make_coffee  # здесь Ruby предполагает self.make_coffee

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

:001 > class Father
:002?>  def check_self(object)
:003?>    object == self
:004?>  end
:005?> end
 => nil
:006 > son = Father.new
 => #<Father:0x82507d0>
:007 > son.check_self(son)
 => true
:008 > son.check_self(Father)
 => false

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

Зато внутри объявления класса (вне методов экземпляра) self указывает на этот объект-класс, что выглядит вполне логично.

:001 > class Father
:002?>   puts "Внутри объявления класса self — это #{self}"
:003?>   def print_self
:004?>     puts "Внутри метода self — это #{self}"
:005?>   end
:006?> end
Внутри объявления класса self — это Father
 => nil
:007 > son = Father.new
 => #<Father:0x8d29800>
:008 > son.print_self
Внутри метода self — это #<Father:0x8d29800>
 => nil

Хорошо, вернемся к предыдущему примеру с кофемашиной. Там в строке 008 вызывается make_coffee объекта saeco, значит, внутри этого метода self является объектом saeco. В вызове метода puts пропущен хозяин-объект, поэтому на его месте надо представлять self:

self.puts "Готовим воду и зёрна"
self.puts "Варим и наливаем кофе"

Но постойте, у объекта saeco есть только метод make_coffee! Или нет?

Наследование и класс Object

Все классы в Ruby наследуют от системного класса Object (если явно не указан другой класс). Запись

class CoffeeMachine
end

является синтаксическим сахаром для

class CoffeeMachine < Object
end

Знак «меньше» не выполняет никакого сравнения, здесь его нужно воспринимать как стрелку влево, и читать «класс Object является предком класса CoffeeMachine».

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

Класс Object не корневой в цепочке наследования, таковым является BasicObject. Создание этих классов происходит автоматически во время запуска любого приложения. В редких случаях разработчику может понадобится наследовать прямо от BasicObject, в этой статье они не рассматриваются.

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

Организация методов в классе

Вновь обратим наши взоры на компанию «Гурман». Дела там улучшаются: продажи «Кофемашины» превысили ожидаемые в два раза и держатся на этой отметке, пресса публикует восторженные рецензии. Руководство и инвесторы выдохнули с облегчением, появилось даже свободное время. А что делают в больших фирмах, когда нечего делать? Верно — сражаются за качество!

class CoffeeMachine
  def make_coffee
    get_water(200)  # набираем воду
    get_beans(50)   # набираем зёрна
    prepare_beans   # готовим зёрна
    boil_water      # кипятим воду
    pour_coffee     # наливаем кофе в чашку
  end

  def get_water(mls)
    puts "Набираем в ёмкость #{mls} мл воды."
  end

  def get_beans(grams)
    puts "Отбираем из контейнера #{grams} г зёрен кофе."
  end

  #...
end

def boil_water
  self.puts "Кипятим воду в ёмкости."
end

def boil_water
  puts "Кипятим воду в ёмкости."
end

class CoffeeMachine
  def make_coffee
    get_water(200)
    get_beans(50)
    #...
  end

  protected

  def get_water(mls)
    # ...
  end

  #...
end

:030 > saeco = CoffeeMachine.new
 => #<CoffeeMachine:0x8df6940>
:031 > puts self
main
 => nil
:032 > saeco.boil_water
NoMethodError: protected method 'boil_water' called for #<CoffeeMachine:0x8df6940>
:033 > saeco.make_coffee
Набираем в ёмкость 200 мл воды.
Отбираем из контейнера 50 г зёрен кофе.
Жарим, мелем зёрна и засыпаем в ёмкость.
Кипятим воду в ёмкости.
Наливаем кофе в кружку.
 => nil

:034 > class Cleaner
:035?>   def clean(machine)
:036?>     machine.get_water(200)
:037?>     machine.boil_water
:038?>     machine.pour_coffee
:039?>   end
:040?> end
 => nil
:041 > class MachineCleaner < CoffeeMachine
:042?>   def clean(machine)
:043?>     machine.get_water(200)
:044?>     machine.boil_water
:045?>     machine.pour_coffee
:046?>   end
:047?> end
 => nil
:048 > cleaner = Cleaner.new
 => #<Cleaner:0x8dbc2cc>
:049 > machine_cleaner = MachineCleaner.new
 => #<MachineCleaner:0x8e2450c>
:050 > cleaner.clean(saeco)
NoMethodError: protected method 'get_water' called for #<CoffeeMachine:0x8df6940>
:051 > machine_cleaner.clean(saeco)
Набираем в ёмкость 200 мл воды.
Кипятим воду в ёмкости.
Наливаем кофе в кружку.
 => nil

Наследование на практике

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

class CappuccinoMachine
  def create_foam
    prepare_milk
    push_foam
  end

  private

  def prepare_milk
    puts "Отбираем и кипятим молоко"
  end

  def push_foam
    puts "Выпускаем молочную пенку в чашку"
  end
end

class CappuccinoMachine < CoffeeMachine
  def create_foam
    #...
  end

  #...
end

class CapsuleMachine < CoffeeMachine
  def make_coffee
    get_water(200)
    prepare_capsule
    boil_water
    pour_coffee
  end

  private

  def prepare_capsule
    puts "Вскрываем капсулу и высыпаем кофе в ёмкость."
  end
end

:001 > class OldMan
:002?>   def say_wisdom
:003?>     puts "Народу много, а людей немного."
:004?>   end
:005?> end
 => nil
:006 > class Man < OldMan
:007?>   def say_wisdom
:008?>     super
:009?>     puts "Так мой предок говаривал"
:010?>   end
:011?> end
 => nil
:012 > man = Man.new
 => #<Man:0x88a0d9c>
:013 > man.say_wisdom
Народу много, а людей немного.
Так мой предок говаривал
 => nil

Модули

Что ж, рано или поздно это должно было случиться. Маркетологи «Гурмана», вдохновленные успешными продажами капсульной модели, требуют срочно начать выпуск делюкс-версии: капсульной кофемашины с капучинатором!

Кажется, инженеры зашли в тупик. У них есть классическая «Кофемашина» на зёрнах и два ее наследника: «Капучинщик» с капучинатором и капсульная модель с модифицированным методом make_coffee. Если продолжать наследование и дальше, чтобы получить капсульный make_coffee + капучинатор, уйти от дублирования кода не получится, какую из последних двух моделей не взять!

И тут на помощь приходят модули Ruby. Модуль представляет собой именованную группу. Если в ней разместить методы, их можно будет «подмешать» к методам любого класса.

Сила модулей в том, что он может одновременно входить в состав различных классов, а в один класс к тому же можно «подмешивать» различные модули, за счет чего достигается сумасшедшее количество комбинаций функциональных возможностей объекта без дублирования кода.

Методы капучинатора — очень хорошие кандидаты для вынесения в модуль, потому что они должны присутствовать сразу в двух моделях (классах) и отсутствовать в двух других.

module Cappuccinator
  def create_foam
    prepare_milk
    push_foam
  end

  private

  def prepare_milk
    puts "Отбираем и кипятим молоко"
  end

  def push_foam
    puts "Выпускаем молочную пенку в чашку"
  end
end

Теперь надо включить этот модуль в «Капучинщик», удалив его старые методы:

class CappuccinoMachine < CoffeeMachine
  include Cappuccinator
end

Модель капсульной кофемашины с капучинатором получается так же просто:

class CapsuleCappuccino < CapsuleMachine
  include Cappuccinator
end

Раз капсульную машину с капучинатором отнесли к топовой модели, можно запрограммировать в ней основы латте-арта:

class CapsuleCappuccino < CapsuleMachine
  include Cappuccinator

  def push_foam
    puts "Красивыми узорами выкладываем пену в чашку."
  end

  private :push_foam
end

Но инженеры уже задницей чувствуют, что завтра может поступить команда включить латте-арт еще в какую-то модель! Наверное, лучше вынести его в отдельный модуль:

module LatteArt
  private

  def push_foam
    puts "Красивыми узорами выкладываем пену в чашку."
  end
end

Тогда CapsuleCappuccino, очевидно, можно переписать:

class CapsuleCappuccino < CapsuleMachine
  include Cappuccinator
  include LatteArt
end

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

Переменные объекта

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

Локальные переменные методов удовлетворяют последнему условию, но для хранения долгосрочной информации не годятся, потому что уничтожаются после выполнения метода. Кроме того, они даже не видны в соседних методах, что затрудняет обмен информацией между подзадачами.

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

В отличие от локальных переменных, обращение к неинициализированной (без присвоенного раньше значения) переменной объекта не приводит к ошибке, просто возвращается nil.

Управление состоянием

Чтобы извлечь пользу из объекта, с ним нужно взаимодействовать и в какой-то мере контролировать процессы, происходящие внутри него. Та же кофемашина будет бесполезным хламом, если у нее не будет кнопки «Пуск/Стоп», носика, из которого льется приготовленный кофе, и индикатора, показывающего, что устройство работает.

В Ruby всё взаимодействие с объектом происходит через его методы и только через них. Как только это понимаешь, объектно-ориентированный мир становится простым до невозможности: есть только объекты, ощетинившиеся иголками методов, и всё!

Поскольку методы могут принимать аргументы, с их помощью мы можем впустить внутрь объекта какую-то информацию. А раз каждый метод в Ruby возвращает значение, таким образом объект может сообщить нам о своем состоянии или передать результаты своей работы.

class CoffeeMachine
  # геттер
  def cups_count
    @cups_count  # отдаем наружу (показываем) значение переменной
  end

  # сеттер
  def cups_count=(count)
    @cups_count = count  # присваиваем значение, пришедшее извне
  end
end

class CoffeeMachine
  attr_accessor :cups_count
end

class CoffeeMachine2
  # неудобный сеттер
  def set_cups_count(count)
    @cups_count = count
  end
end

machine = CoffeeMachine2.new
machine.set_cups_count(1)

machine = CoffeeMachine.new
machine.cups_count = 1  # то же, что и machine.cups_count=(1)

class CoffeeMachine
  attr_accessor :cups_count

  def set_default_cups_count
    cups_count = 1
  end
end

:008 > nespresso = CoffeeMachine.new
 => #<CoffeeMachine:0x904d61c>
:009 > nespresso.set_default_cups_count
 => 1
:010 > nespresso.cups_count
 => nil

class CoffeeMachine
  attr_accessor :cups_count

  def set_default_cups_count
    self.cups_count = 1
  end
end

:008 > bosch = CoffeeMachine.new
 => #<CoffeeMachine:0x914801c>
:009 > bosch.set_default_cups_count
 => 1
:010 > bosch.cups_count
 => 1

class CoffeeMachine
  attr_accessor :cups_count

  def initialize(count = 1)
    @cups_count = count
  end
end

:008 > bosch = CoffeeMachine.new(2)
 => #<CoffeeMachine:0x917f5f8>
:009 > bosch.cups_count
 => 2

Синглтон методы

Пока мы разбирались с геттеро-сеттерами, руководство «Гурмана» поставило перед инженерами очередную задачу: каждый раз, когда с конвейера сходит тысячная кофемашина, должна раздаваться радостная мелодия, вдохновляющая работников на трудовые подвиги.

До сих пор инженеры занимались проектированием собственно кофемашин, но ведь это не обязанность кофемашины — считать, сколько ее было выпущено, и уж тем более подавать какие-то увеселительные сигналы. И вряд ли это обязанность конвейера (класса) — играть мелодии. Скорее всего, этим должен заниматься специальный объект, Радостный Счетчик.

Однако, тут у инженеров проблема: как Счетчик узнает о том, что с конвейера сошел очередной готовый объект? Если задуматься, то это событие происходит одновременно с вызовом метода new класса. И уж если с чего начинать, так с него: нужно перезаписать этот метод, вклинив в него оповещение Счетчика о созданном объекте.

Мы уже знаем, что метод new класса попадает из синглтон класса BasicObject. Но как его перезаписать (перекрыть)? Для этого нужно задать метод экземпляра в синглтон классе, который ближе к объекту — в его собственном.

Методы синглтон класса еще называют синглтон методами. Чтобы их задать, существует простая форма записи:

def имя_объекта.название_синглтон_метода
 #...
end

Значит, можно перезаписать метод new следующим образом:

def CoffeeMachine.new
  #...
end

Еще мы знаем, что внутри объявления класса self и есть этот класс. Поэтому синглтон методы можно определять прямо внутри класса:

class CoffeeMachine
  def self.new  # self == CoffeeMachine
    #...
  end
end

Наконец, в Ruby есть возможность открыть объявление синглтон класса и записывать там его методы:

class << CoffeeMachine
 # ...
end

а внутри объявления класса это будет выглядеть как:

class CoffeeMachine
  class << self
    def new
      #...
    end
  end
end

Что же должен делать новый метод new? Очевидно, он должен обратиться к «оригинальному» методу и создать объект, после чего отправить сообщение Радостному Счетчику. Однако, поскольку сам метод должен возвращать созданный объект, его придется временно сохранять в локальной переменной:

class CoffeeMachine
  def self.new
    machine = super # создаем объект с помощью метода new предка
    # как-то уведомляем Счетчик
    machine # возвращаем созданный объект (неявный return)
  end
end

Попробуем теперь представить сам Радостный Счетчик. Бесспорно, он должен хранить у себя количество созданных объектов — нужна переменная. Когда должен происходить проигрыш мелодии? Когда это количество кратно тысяче. Значит, нужен хитрый сеттер, который будет не только присваивать переменной значение, но и делать проверку на кратность.

class HappyCounter
  attr_reader :count # удобный способ создать геттер

  # сеттер
  def count=(value)
    @count = value
    play_melody if premium_count?
  end

  def initialize
    @count = 0
  end

  def premium_count?
    @count % 1000 == 0 # проверяем остаток от деления
  end

  private

  def play_melody
    puts "Та-дааам!!!"
  end
end

Хммм, сеттер публичный, выходит, любители танцев могут безнаказанно устанавливать любое количество выпущенных объектов, кратное тысяче, и плясать до упаду. Но и сделать его частным нельзя, иначе как тогда увеличивать переменную @count?

Но ведь можно изолировать весь Счетчик, сделав его собственностью объекта CoffeeMachine! Тогда взаимодействовать со Счетчиком сможет только сам конвейер. Для этого в CoffeeMachine понадобится переменная для хранения объекта и сеттер (а вот геттера не будет, тогда к созданному Счетчику извне никто не доберется).

Сеттер можно задать так:

class CoffeeMachine
  def self.counter=(object)
    @counter = object
  end

  #...
end

А можно воспользоваться методом класса attr_writer, но для этого понадобится «войти» в синглтон класс:

class CoffeeMachine
  class << self
    attr_writer :counter
  end

  #...
end

Теперь становится понятно, как уведомить Счетчик о создании нового объекта:

class CoffeeMachine
  def self.new
    machine = super
    @counter.count += 1 # то же, что и @counter.count = @counter.count + 1
    machine
  end

  #...
end

:030 > CoffeeMachine.counter = HappyCounter.new
 => #<HappyCounter:0x8738edc @count=0>
:031 > 999.times do
:032 >   CoffeeMachine.new
:033?> end
 => 999
:034 > premium_machine = CoffeeMachine.new
Та-дааам!!!
 => #<CoffeeMachine:0x8930c80>

Объекты повсюду

Очень легко дается понимание объектов, которые являются примерными копиями материальных вещей из реальной жизни. Вот объект Автомобиль: у него есть масса, цвет и максимальная скорость, он может проехать из точки А в точку Б, причем не один, а вместе с объектом Груз и объектом Водитель. Мы даже легко можем представить, что Автомобиль — составной объект, внутри которого есть Двигатель, Коробка передач и Топливный бак, а масса и максимальная скорость являются сложными и непостоянными величинами, зависящими от всех этих составляющих.

Гораздо сложнее увидеть в качестве объекта совершенно абстрактные понятия.

Число в Ruby — объект. В жизни они — самая настоящая абстракция: если семь самураев или семь футов под килем можно хотя бы увидеть, то просто семь существует только в голове мыслящего существа. И тут — бац! — Ruby, словно пифагореец, который считал, что весь мир построен из чисел, шокирует нас заявлением, что число — объект, и его можно пощупать.

Но что полезного может делать семерка как объект? Это же просто число! Оказывается, работы немало: в Ruby каждое число отвечает за сложение себя с другим объектом. И за вычитание, и остальные арифметические операции — тоже. Там, где другой интерпретатор сказал бы «ага, 2 плюс 3 — это же пять!», Ruby говорит двойке «вот тебе тройка, складывайся с ней как хочешь».

Может, арифметика за счет объекта и кажется немного притянутой за уши, тем более, что Ruby всё равно дает использовать соответствующие методы под видом привычных операторов (синтаксический сахар). Вместо того, чтобы писать

2.+(3)

пишем обычное

2 + 3

Правомерность обеих записей, скорее, дает ощущение целосности и последовательности в мире Ruby. Ведь не одним сложением ограничивается число. Взять, к примеру, определение его четности. Можно использовать известную технику с остатком от деления на два:

if 7 % 2 == 0
  # если семь — четное, что-то делаем
end

Можно даже вынести эту логику в отдельный метод:

def is_even?(number)
  number % 2 == 0
end

is_even?(7) # => false

Но в любом случае мы пытаемся определить внутреннее свойство числа с помощью внешней функции, в то время, как более натуральным было бы отдать это на откуп черному ящику. И то, что числа являются в Ruby объектами, позволяет легко это сделать:

7.even? # => false

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

"Ruby".length # => 4
"Ruby".upcase # => "RUBY"
[1, 3, 4, 2].sort # => [1, 2, 3, 4]
[1, 3, 3, 2].uniq # => [1, 3, 2]

true, false и nil, которые во многих языках являются ключевыми словами, в Ruby тоже объекты.

false.nil? # => false
nil.nil? # => true

Единственная магия, которую невозможно объяснить в рамках языка — как Ruby получает само значение из объекта, который представляет простой тип данных. Даже если бы и существовал метод, который возвращал это значение, оно всё равно было бы еще одним объектом (поскольку в Ruby всё — объект). Но к этому дуализму тоже быстро привыкаешь: тройка для Ruby одновременно и число 3, и объект.

Замысловатые термины

• способность объекта быть черным ящиком — инкапсуляция;
• совокупность публичных методов объекта составляют его интерфейс;
• возможность перекрывать методы в потомках — полиморфизм.