"Объектно-ориентированный" - какое же это заразное выражение. Назовите что-то "объектно-ориентированным" - и Ваша фраза будет оччень умно. О Ruby говорят как об объектно-ориентированном языке; а что же точно означает "Объектно-ориентированный"?
Есть множество вариантов ответа на этот вопрос, но все они, вероятно, сводятся к одному и тому же. Чем слихком быстро их просуммировать, давайте немного поразмышляем о парадигме традиционного программирования
Традиционно задача в программировании сводится к некоторому виду представления данных, и процедурам, которые призводят операции над этими данными. В соответствии с этой моделью, данные являются инертными, пассивными и беспомощными; они полностью отданы на милость жирному телу процедур, которые активны, логичны и всемогущи.
Проблема, заключающаяся в таком подходе в том, что программы пишутся программистами, которые всего лишь люди и могут держать в голове ясными не так много деталей в данный момент. Как только проект вырастает, его процедурный слой растет до таких размеров, когда становится затруднительно помнить, как он работает в целом. Малейшие оплошности в мышлении и ошибки в наборе с большой долей вероятности приведут к хорошо упрятанным багам. Сложные и непредусмотренные взаимодействия начинают складываться в процедурном слое, его поддержка становится похожей на то, как если бы вы несли рассерженного спрута, пытаясь не допустить касания щупальцами Вашего лица. Существуют принципы программирования, которые могут помочь минимизировать и локализовать баги при традиционной парадигме, но есть лучшее решение, которое включает в себя фундаментальную смену принципов нашей работы.
Что нам дает объектно-ориентированное программирование - оно позволяет перенести повторяющуюся логику и механизмы взаимодействия на сами данные; оно меняет концепцию даннык с пассивной на активную. Иначе говоря,
* Мы более не рассматриваем данные как некоторую коробку с откытой крышкой, которая позволяет нам заглянуть вовнутрь и пожевать содержимое.
* ы начинаем рассматривать данные как некий закрытый механизм с четко определенными рычажками и индикаторами.
То, что мы ранее назвали "устройством", может быть очень простым или сложным внутри; мы не можем определить это, глядя снаружи; также мы не позволяем себе заглянуть вовнутрь (за исключением случев, когда мы абсолютно уверены, что с дизайном что-то не так); таким образом, для взаимодействия от нас требуется лишь пощелкать переключателями и прочитать значения индикаторов. Когда этот механизм построен, нам не нужно думать как он работает внутри.
Можно подумать, что таким образом мы лишь усложняем себе работу, однако данный подход дает возможность предотвратить ситуации, когда что-то идет не так, как предполагалось.
Давайте нанем с примера; он слишком прост, чтобы быть практичным, однако способен, по крайней мере, частично проиллюстрировать саму концепцию. В Вашей машине есть одометр. Его работа заключается, среди прочего, в том, чтобы подсчитывать расстояние, пройденное с момента последнего нажатаи я его кнопки сброса. Как это можно смоделировать на языке программирования? На С одоиметр можно представить просто числовой переменной, возможно, с типом float. Такая программа будет работать с этой переменной увеличивая ее значение маленькими шагами, сбрасывая ее значение в ноль при необходимости. Что же здесь не так? Из-за ошибки в программе этой переменной может быть присвоено неверное значение просто по воле случая. Любой, кто программировал на С, знает как это часами или целыми днями выслеживал подобные ошибки, которые при обнаружении оказываются абсурдно элементарными. (Момент обнаружения бага обычно прослеживается по звуку шлепка по лбу.)
Решение той же самой проблемы в объектно-ориентированном (ОО) контексте будет рассматриваться с совершенно другой стороны. Первым вопросом программиста при разработке модели одометра будет не "какой из существующих типов танных наиболее полно отражает порядок вещей", а "какой точно предполагается работа этой штуки". В этом и есть коренное различие. Необходимо потратить немного больше времени, обдумывая для чего же точно нужен одометр и как окружающий мир может с ним взамодействовать. Мы решаем построить небольшое устройство с управлением, позволяющем увеличить его показания, сбросить их, прочитать значение и ... ничего более...
Мы не даем возможности установить произвольное значение - почему? А потому что, как все мы знаем, одометр не работает таким образом. Есть только определенные действия, которые разрешено проводить с одометром. Таким образом, если что-то в программе пытается установить некоторое посторонне значение (скажем, целевую температуру системы климат-контроля машины) в одометр, немедленно станет ясно, что происходит что-то не то. Во время выполнения программы (или, возможно, во время компиляции, - зависит от вида языка) нам будет указано, что недопустимо присваивать объекту Tripmeter произвольные значения. Сообщение может быть не настолько ясным, но достаточно близким к этому. Это не предотвращает ошибки, не так ли? Но это быстро укажет нам направление поиска причины. Это только один из способов, которым ОО программирование может предотвратить кучу впустую потраченного времени.
Мы обычно поднимаемся на уровень абстракции выше чем здесь, Потому как оказывается удобным построить factory, которая производит подобные устройства, чем создавать их поодиночке. Маловероятно, что мы прямо будем создавать объект одометр; вместо этого мы предпочтем, чтобы нужное их количество было построено по пределенному шаблону. Шаблон (или, если Вам больше нравится, tripmeter factory) соотносится с тем, что называют "классом", а отдельно взятый одометр соотносится с "объектом". В большинстве ОО языков требуется, чтобы класс был определен до того, как мы можем получить объект нового типа, но не в Ruby.
Здесь ничего не сказано о том, что использование ОО языка вынуждает создавать хороший ОО дизайн. В самом деле, на любом языке можно написать насквозь нечитаемую, неаккуратную, плохо продуманную, глючную и неустойчивую в работе программу. Что Ruby дает Вам (особо по сравнению с С++), так это то что, когда Вы прорабатываюте детали, то не чувствуется желания ухудшить стиль для сохранения усилий. По ходу повествования мы будем обсуждать как же Ruby идет к этой прекрасной цели. Следующей темой будет "кнопочки и рычажки" (методы объектов), от которых мы перейдем к "фабрикам" (классам). Вы еще здесь?
Источник: www.opennet.ru
К началу статьи
