С другой стороны, ООП – это специальный образ мышления, особая философия. Необходимость научиться мыслить новыми понятиями вызывает затруднения у начинающих программистов. В данном случае бесполезно заучивать определения – необходимо понять суть.

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

Обычно в этом месте начинающие программисты восклицают: «Ну почему так сложно?!» Если вы хотите уметь работать с эффективными и универсальными инструментами, без сложностей не обойтись. Но могу вас успокоить – в повседневной жизни мы постоянно используем проекты и абстракцию разных уровней. Это естественный образ мышления человека! Для облегчения понимания рассмотрим простой пример.

Допустим, перед вами стоит задача регулярно косить траву на лужайке перед домом. Что требуется для решения этой задачи? Прежде всего, нужна газонокосилка. Перед покупкой газонокосилки вы решаете, какой она будет – бензиновой или электрической, ручной или на колесиках. Это абстракция на уровне типа газонокосилки. Нет никакой необходимости спускаться в абстракции ниже, до уровня карбюратора или гаек в составе газонокосилки. В данном случае вы интуитивно верно выбираете уровень абстракции, руководствуясь элементарным здравым смыслом. Помните, что готовые решения и правила достаточно условны, а окончательный выбор уровня абстракции и инструментов остается за вами.

У завода-изготовителя газонокосилок есть подробные чертежи, описание технологии производства, свойств изделия и приемов работы с ним. В программировании такой описательный набор называется класс. Но самое подробное описание изделия – это еще не изделие. Заказчик обращается на завод с запросом на изготовление экземпляра газонокосилки. В программировании это называется экземпляр класса или объект класса. В целом, термины «объект» и «экземпляр» взаимозаменяемы, но есть тонкие смысловые нюансы. Термин «объект» чаще используется, когда делается смысловой акцент на функциональной сущности объекта реального мира, а термин «экземпляр» чаще применяется, когда идет речь о структурной единице программного кода.

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

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