Что такое классы и объекты в ООП?

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

Эпоха динозавров без классов и объектов

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

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

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

Тип данных: Колесо {
  переменная резина: Резина;
  переменная диск: Диск;
}
 
Тип данных: Автомобиль {
  переменная число_дверей: Целое_число;
  переменная объем_двигателя: Вещественное_число;
  переменная марка: Строка;
  переменная модель: Строка;
  переменная колесо: Колесо;
  ...
}

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

Основная идея классов, объектов и ООП в целом

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

Одновременное почёсывание большого числа лохматых голов дало нехилый заряд статического электричества и у кого-то проскочила дельная искра: добавить в структуры поведенческий аспект. То есть, создать такую концепцию, при которой структурный тип не только содержал бы в себе все свои данные, но и сам бы с ними работал: загружал, сохранял, изменял и т.д.

Класс: Автомобиль {
  ...
  переменная марка: Строка;
  переменная модель: Строка;
  ...
  функция заголовокДляПрайсЛиста() {
    вернуть марка + " " + модель;
  }
}

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

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

Объектно ориентированное «программирование» в жизни

В умных книжках вас наверняка напугали «интуитивно понятной» фразой «объект — это экземпляр класса». Давайте возьмем что-то менее интуитивное, но более понятное — из жизни.

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

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

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

результат = матрица_один->суммировать(матрица_два);

14.07.2010 | 15:36

Добавить комментарий