ООП с примерами (часть 2)
Волею судьбы мне приходится читать спецкурс по паттернам проектирования в вузе. Спецкурс обязательный, поэтому, студенты попадают ко мне самые разные. Конечно, есть среди них и практикующие программисты. Но, к сожалению, большинство испытывают затруднения даже с пониманием основных терминов ООП.
Для этого я постарался на более-менее живых примерах объяснить базовые понятия ООП (класс, объект, интерфейс, абстракция, инкапсуляция, наследование и полиморфизм).
Первая часть посвящена классам, объектам и интерфейсам.
Вторая часть, представленная ниже, иллюстрирует инкапсуляцию, полиморфизм и наследование
Инкапсуляция
Представим на минутку, что мы оказались в конце позапрошлого века, когда Генри Форд ещё не придумал конвейер, а первые попытки создать автомобиль сталкивались с критикой властей по поводу того, что эти коптящие монстры загрязняют воздух и пугают лошадей. Представим, что для управления первым паровым автомобилем необходимо было знать, как устроен паровой котёл, постоянно подбрасывать уголь, следить за температурой, уровнем воды. При этом для поворота колёс использовать два рычага, каждый из которых поворачивает одно колесо в отдельности. Думаю, можно согласиться с тем, что вождение автомобиля того времени было весьма неудобным и трудным занятием.
Теперь вернёмся в сегодняшний день к современным чудесам автопрома с коробкой-автоматом. На самом деле, по сути, ничего не изменилось. Бензонасос всё так же поставляет бензин в двигатель, дифференциалы обеспечивают поворот колёс на различающиеся углы, коленвал превращает поступательное движение поршня во вращательное движение колёс. Прогресс в другом. Сейчас все эти действия скрыты от пользователя и позволяют ему крутить руль и нажимать на педаль газа, не задумываясь, что в это время происходит с инжектором, дроссельной заслонкой и распредвалом. Именно сокрытие внутренних процессов, происходящих в автомобиле, позволяет эффективно его использовать даже тем, кто не является профессионалом-автомехаником с двадцатилетним стажем. Это сокрытие в ООП носит название инкапсуляции.
Инкапсуляция – это свойство системы, позволяющее объединить данные и методы, работающие с ними, в классе и скрыть детали
реализации от пользователя.
Инкапсуляция неразрывно связана с понятием интерфейса класса. По сути, всё то, что не входит в интерфейс, инкапсулируется в классе.
Абстракция
Представьте, что водитель едет в автомобиле по оживлённому участку движения. Понятно, что в этот момент он не будет задумываться о химическом составе краски автомобиля, особенностях взаимодействия шестерён в коробке передач или влияния формы кузова на скорость (разве что, автомобиль стоит в глухой пробке и водителю абсолютно нечем заняться). Однако, руль, педали, указатель поворота (ну и, возможно, пепельницу) он будет использовать регулярно.
Абстрагирование – это способ выделить набор значимых характеристик объекта, исключая из рассмотрения незначимые. Соответственно, абстракция – это набор всех таких характеристик.
Если бы для моделирования поведения автомобиля приходилось учитывать химический состав краски кузова и удельную теплоёмкость лампочки подсветки номеров, мы никогда бы не узнали, что такое NFS.
Полиморфизм
Любое обучение вождению не имело бы смысла, если бы человек, научившийся водить, скажем, ВАЗ 2106 не мог потом водить ВАЗ 2110 или BMW X3. С другой стороны, трудно представить человека, который смог бы нормально управлять автомобилем, в котором педаль газа находится левее педали тормоза, а вместо руля – джойстик.
Всё дело в том, что основные элементы управления автомобиля имеют одну и ту же конструкцию и принцип действия. Водитель точно знает, что для того, чтобы повернуть налево, он должен повернуть руль, независимо от того, есть там гидроусилитель или нет.
Если человеку надо доехать с работы до дома, то он сядет за руль автомобиля и будет выполнять одни и те же действия, независимо от того, какой именно тип автомобиля он использует. По сути, можно сказать, что все автомобили имеют один и тот же интерфейс, а водитель, абстрагируясь от сущности автомобиля, работает именно с этим интерфейсом. Если водителю предстоит ехать по немецкому автобану, он, вероятно выберет быстрый автомобиль с низкой посадкой, а если предстоит возвращаться из отдалённого маральника в Горном Алтае после дождя, скорее всего, будет выбран УАЗ с армейскими мостами. Но, независимо от того, каким образом будет реализовываться движение и внутреннее функционирование машины, интерфейс останется прежним.
Полиморфизм – это свойство системы использовать объекты с одинаковым интерфейсом без информации о типе и внутренней структуре объекта.
Например, если вы читаете данные из файла, то, очевидно, в классе, реализующем файловый поток, будет присутствовать метод похожий на следующий: byte[] readBytes( int n );
Предположим теперь, что вам необходимо считывать те же данные из сокета. В классе, реализующем сокет, также будет присутствовать метод readBytes. Достаточно заменить в вашей системе объект одного класса на объект другого класса, и результат будет достигнут.
При этом логика системы может быть реализована независимо от того, будут ли данные прочитаны из файла или получены по сети. Таким образом, мы абстрагируемся от конкретной специализации получения данных и работаем на уровне интерфейса. Единственное требование при этом – чтобы каждый используемый объект имел метод readBytes.
Наследование
Представим себя, на минуту, инженерами автомобильного завода. Нашей задачей является разработка современного автомобиля. У нас уже есть предыдущая модель, которая отлично зарекомендовала себя в течение многолетнего использования. Всё бы хорошо, но времена и технологии меняются, а наш современный завод должен стремиться повышать удобство и комфорт выпускаемой продукции и соответствовать современным стандартам.
Нам необходимо выпустить целый модельный ряд автомобилей: седан, универсал и малолитражный хэтч-бэк. Очевидно, что мы не собираемся проектировать новый автомобиль с нуля, а, взяв за основу предыдущее поколение, внесём ряд конструктивных изменений. Например, добавим гидроусилитель руля и уменьшим зазоры между крыльями и крышкой капота, поставим противотуманные фонари. Кроме того, в каждой модели будет изменена форма кузова.
Очевидно, что все три модификации будут иметь большинство свойств прежней модели (старый добрый двигатель 1970 года, непробиваемая ходовая часть, зарекомендовавшая себя отличным образом на отечественных дорогах, коробку передач и т.д.). При этом каждая из моделей будет реализовать некоторую новую функциональность или конструктивную особенность. В данном случае, мы имеем дело с наследованием.
Наследование – это свойство системы, позволяющее описать новый класс на основе уже существующего с частично или полностью заимствующейся функциональностью. Класс, от которого производится наследование, называется базовым или родительским. Новый класс – потомком, наследником или производным классом.
Необходимо отметить, что производный класс полностью удовлетворяет спецификации родительского, однако может иметь дополнительную функциональность. С точки зрения интерфейсов, каждый производный класс полностью реализует интерфейс родительского класса. Обратное не верно.
Действительно, в нашем примере мы могли бы произвести с новыми автомобилями все те же действия, что и со старым: увеличить или уменьшить скорость, повернуть, включить сигнал поворота. Однако, дополнительно у нас бы появилась возможность, например, включить противотуманные фонари.
Отсутствие обратной совместимости означает, что мы не должны ожидать от старой модели корректной реакции на такие действия, как включения противотуманок (которых просто нет в данной модели).
Причуды абстракций
Что такое абстракция?
Википедия определяет абстракцию и процесс абстрагирования следующим образом:
Абстра́кция (от лат. abstractio — отвлечение) — отвлечение в процессе познания от несущественных сторон, свойств, связей объекта (предмета или явления) с целью выделения их существенных, закономерных признаков; абстрагирование; теоретическое обобщение как результат такого отвлечения.
В европейской философии и логике абстрагирование трактуется как способ поэтапного продуцирования понятий, которые образуют всё более общие модели — иерархию абстракций. Наиболее развитой системой абстракций обладает математика. Степень отвлечённости обсуждаемого понятия называется уровнем абстракции. В зависимости от целей и задач, можно рассуждать об одном и том же объекте на разных уровнях абстракции.
Гради Буч определяет понятие абстракции значительно проще, но смысл тот же:
Абстракция выделяет существенные характеристики некоторого объекта, отличающие его от всех других объектов.
Зачем нужна абстракция?
Абстракции выполняют защитную функцию и помогают нам не сойти с ума от переизбытка информации. Представьте, как бы нам жилось, если при письме шариковой ручкой пришлось бы думать о том, что миллиарды молекул чернил взаимодействуют с молекулами бумаги, чтобы получилась буква. Другими словами, не тратя время на ненужные подробности, мы можем ухватить самую суть — взглянуть на проблему «сверху». 
Если бы не фотография с высоты птичьего полета, можно ли было бы себе представить насколько правильно спроектирована Барселона? Кстати, про пример с шариковой ручкой, читать бы тоже не получилось — начертания одной и той же буквы на письме отличаются даже у одного человека.
Абстрактное мышление — это механизм, который позволяет нам перерабатывать и усваивать кучу новых сведений. Если бы не было абстракции, то единственный вариант для нас — это остаться очень примитивными существами. 
В Бразилии живет племя небольшое племя индейцев Пираха. Представители этой народности обладают крайне скудным абстрактным мышлением. Их алфавит состоит из трех гласных и восьми согласных. У них нет слов, обозначающих цифры, вместо цифр у них два понятия — несколько и много. У них нет цветов — только понятия светлый и темный, времени и истории — они живут только сегодняшним днем и помнят только то. что помнит старейший из ныне живущих; нет — религии, ремесел, искусства. У них еще много чего нет в нашем привычном понимании. И это все потому, что не развито абстрактное мышление. Правда, справедливости ради, стоит отметить, что при этом они себя ощущают абсолютно счастливыми людьми!
Итак, абстрагирование нам нужно как способ познания и описания окружающего мира, для обмена информацией друг с другом. Абстракции позволяют провести декомпозицию предметной области на набор понятий и связей между ними. 
На картинке изображен Legoland в Лондоне. Несмотря на то, что все предметы собраны из детского конструктора, мы без труда узнаем в них дома, окна, двери, городские кварталы, людей.
Барьеры и побочные эффекты абстракций
Чтобы понять ключевые свойства абстракций проведем аналогию с построением проекций на плоскость. 
Предположим, что у нас есть три фигуры: шар, цилиндр и параллелепипед, при этом ось симметрии цилиндра, проходящая через центры окружностей в основании, параллельна какой-нибудь оси симметрии параллелепипеда. Очевидно, что можно выбрать две плоскости для построения проекций таким образом, что шар и цилиндр спроецируются в окружности, а цилиндр и параллелепипед — в прямоугольники.
Проекция в нашем примере иллюстрирует абстракцию объекта — геометрической фигуры. Что мы видим — на одной плоскости не отличишь проекции шара и цилиндра, а на другой — цилиндра и параллелепипеда. Этот эффект называется барьером абстракции. Абстракция представляет не весь объект целиком, а только лишь его существенный набор характеристик.Нужно быть готовым к тому, что некоторые очень непохожие друг на друга объекты, могут стать неразличимыми. Если это неудобно, то нужно выбирать другой набор абстракций.
С другой стороны, как мы видим из примера, цилиндр, может проецироваться и в окружность, и в прямоугольник — объекты с различными геометрическими свойствами, отличными от тех, что есть у цилиндра. Наличие у абстракции собственных свойств, отличных от свойств абстрагируемого объекта, называется побочным эффектом абстракции.
На самой первой картинке изображены две фигуры, собранные из щепок, так что при определенном освещении они отбрасывают «человеческие тени». Мне, например, кажется, что там один силуэт мужской, а другой — женский. Это тоже побочный эффект абстракций. Теперь мы можем классифицировать все фигуры по их тени.
Примеры абстракций
| Сфера применения | Абстракция | Комментарий |
|---|---|---|
| Целые числа | Число из кольца Zp, где p = 2^разрядность (8, 16, 32, 64 бита) | Данная абстракция позволяет представить целые числа только из отрезка –p/2+1 до p/2. Побочный эффект – проблема переполнения. |
| Вещественные числа | Числа с плавающей точкой | Вещественных чисел несчетное число, а чисел с плавающей точкой — всего лишь конечное. Это значит, что несчетное количество вещественных чисел представлены одним числом с плавающей точкой. Побочный эффект – ошибка округления, из-за который два числа нельзя сравнивать с помощью операции сравнения, а лишь по модулю некоторого маленького epsilon |a-b| a == b, или a/b*1000 может сильно отличаться от a*1000/b. Появилась даже целая дисциплина в математике – численные методы, которая изучает как организовать вычисления с плавающей точкой так, чтобы результаты не сильно отличались от вычислений с вещественными числами. |
| Деньги | Числа с плавающей точкой | Погрешность округления чисел с плавающей точкой делает, если не невозможным их использование для финансовых операций, то, по крайней мере, сильно усложняет жизнь. В любом случае, я бы сначала подумал в сторону написания отдельного класса для денежных единиц. |
| Изображение | Машинная графика | Машинная графика развивается семимильными шагами, чтобы сделать изображение на экране компьютера все более реалистичным. |
| Программное обеспечение | Процедура | Процедура является базовым элементом декомпозиции в процедурном программировании. Побочный эффект — процедура жестко заданная последовательность команд, которую невозможно изменить без переписывания самой процедуры. |
| Программное обеспечение | Класс | О классах будем говорить ниже. |
| Предметная область | Абстракция сущности и связи между сущностями | Побочный эффект — отражает представление, заблуждения, предубеждения и т.д. о предметной области конкретного субъекта. |
| Бизнес-логика | Процедура | Как уже говорилось выше — побочный эффект процедуры — жесткая последовательность команд. Бизнес-логика же подвержена изменениям, как правило содержит много исключений, о которых пользователи обычно забывают рассказать. Попытка представить бизнес-операцию в виде процедуры часто делает терпит неудачу. |
| Программное обеспечение | Поток для распараллеливания операций | Многопоточное программирование получилось настолько сложным для восприятия, что немного людей в нем разбирается. |
| Квадрат — это прямоугольник, у которого все стороны равны. | Класс квадрат нельзя наследовать от прямоугольника. | Классы — это абстракции. У них есть свои собственные свойства, которые отличаются от математических объектов и которые делают невозможным наследование. |
Классы
Гради Буч так определяет ООП:
Объектно-ориентированное программирование — это методология программирования, основанная на представлении программы в виде совокупности объектов, каждый из которых является экземпляром определенного класса, а классы образуют иерархию наследования.
В этом определении самый важный момент — это иерархия наследования. Потому что именно наследование отличает ООП от всех других методологий.
Два основных принципа человеческого мышления — это группировка и обобщение. Классы — это, по сути, абстракции механизмов группировки и обобщения человеческого мозга. Естественно, со своими побочными эффектами и барьером. При этом группировка достигается тем, что похожим объектам сопоставляется один класс, а обобщение в ООП достигается за счет иерархии классов. Иерархии классов реализуются через полиморфизм.
ООП, кстати, интересно еще хотя бы и тем, что это, пожалуй, последняя парадигма программирования на данный момент, которая поддерживается на аппаратном уровне.
Главный побочный эффект классов — они отражают опыт, стереотипы, предубеждения того программиста, который их написал. Отсюда следует, что разные люди получат разный набор классов для одной и той же задачи. Более того, один и тот же человек, решая одну и туже задачу, но в разные моменты времени, получит разный набор классов, просто потому что его жизненный опыт меняется.
Второй побочный эффект, который стоит отметить — чужой код всегда менее понятный, чем свой собственный.
Разберемся почему так происходит. Когда человек пишет код, для него естественнее двигаться снизу вверх — от более низкоуровневых компонент к более высокоуровневым. Сначала написали один класс, потом второй, который зависит от первого, затем третий, который зависти от первого и второго, четвертый — от третьего и т.д.
Когда же человек пытается понять чужой код, он как раз двигается наоборот — сверху вниз. То есть сначала понимает общую суть, затем разбивает на компоненты, потом пытается понять суть каждого компонента и т.д. Часто эти движения мысли снизу вверх и сверху вниз у разных людей не совпадают. Естественно, что изучающему чужой код было бы легче, если разбиение кода на компоненты совпадало с его собственными убеждениями, как надо делать. Если это не так, придется затрачивать определенные усилия, чтобы понять ход мыслей разработчика. Поэтому, когда кто-то говорит, что здесь «полный хардкод», но если я перепишу, то будет все проще и понятнее. Это всегда 100% правда… Но только для него, для остальных ценность переписывания уже не так очевидна.
Кстати, если ничего не предпринимать специально, то при разработке снизу вверх, код становится сильно связанным между собой, то есть не повторно используемым. Чтобы побороть этот эффект надо следовать принципу инверсии зависимостей (The Dependency Inversion Principle).
Проиллюстрируем как проявляется описанный побочный эффект на простом примере. Многие жители крупных городов закупаются в крупных супермаркетах. Предположим, что жена отправляет мужа за покупками и, чтобы он не забыл, как обычно, чего-нибудь, составляет список «для тех кто в танке».
Постараемся проследить ход ее мыслей:
— Так чего я сегодня буду готовить на ужин?
— Надо приготовить чего-нибудь вкусненькое, чтобы побаловать ребенка.
— Так, нужна будет мука, молоко.
— Кажется в миксере сели батарейки.
— Стоп! Ребенку нужны витамины. Морковь. Буду делать морковный сок. и мандарины. Скоро же Новый год!
— А хлеб дома есть? Нет, кажется, нет.Значит, надо купить!
— Еще надо купить масло.
— Забыла про ребенка — витамины. Купить яблоки.
— Чего-то ручка плохо пишет. Наверное скоро кончатся чернила. Надо купить!
— Так, ребенку надо купить сока.
— А еще игрушку — пусть порадуется.
— Картошка у нас есть на борщ? На борщ хватит, но на неделю нет. Значит тоже надо купить.
— Чуть не забыла учительница просила принести две тетради.
— К борщу нужна сметана.
— Вроде сахар кончился.
— Ребенок любит виноград.
— И еще надо купить бутилированной воды.
Когда приходит муж в магазин то, что он обнаруживает? Указанные в списке товары оказываются в разных частях магазина. Обычно список длинный, поэтому запомнить что-либо, что было уже куплено достаточно трудно. На это накладывается, что какие-то отделы временно закрыты — идет выгрузка товаров, какого-то товара нет в продаже, плюс толчея, зимняя одежда. Более опытные товарищи ходят с карандашом или ручкой с очень озабоченным видом и постоянно смотрят в свой список. Но, в итоге, все равно, что-нибудь да забудешь купить. По своему опыту могу сказать, что это «что-нибудь» окажется самым важным, из-за чего вообще и стоило ехать в магазин.
Еще одно важное наблюдение — невозможно по самим абстракциям определить насколько удачными они получились. Это можно сделать, только если мы попытаемся их использовать на практике. И тут уж выясняется, что одни абстракции лучше подходят для задачи, а другие — хуже. А если еще немного изменить исходные условия, то и прежний «хороший» набор абстракций уже может не работать. Например, второй список покупок из примера перестанет работать, если прийти с ним в другой магазин с иным порядком выкладки товаров. Он станет ничем не лучше, чем первый.
Отсюда вывод — невозможно придумать набор классов, который подойдет на все случаи жизни. В статье The Open-Closed Principle это называется стратегическая замкнутость.
Естественный вопрос, а как сразу создавать хорошие абстракции. Увы, но на этот счет нет точного ответа. Зато со временем выработался набор практик, который говорит, как надо поступать, и обещает, что в этом случае будет хороший результат. К таким практикам относится рефакторинг, стандарты кодирования, code review, объектная гимнастика и т.д. Цель данных практик — направить ход мыслей группы разработчиков в одном направлении, тогда шансов, что чужой код будет понятнее, станет больше. Отношение к каждой из практик у отдельно взятого человека зависит лишь от приобретенного им опыта использования практики. Часто слова «Это не работает» надо интерпретировать как «Я пробовал — у меня не получилось». Нет никаких объективных аргументов «ЗА», равно как и «ПРОТИВ».
Так зачем нужно тогда ООП?
Проведем параллели между естественным языком и ООП
| естественный язык | ООП |
|---|---|
| Слово | класс |
| Правила | Синтаксис |
| Жанр | Архитектура |
| литературные приемы | паттерны |
ООП — это инструмент, который создавался с прицелом на большие по размеру программы. Но, это всего лишь один из инструментов, который потребуется, чтобы написать крупный проект.
Меня всегда удивляют, статьи в стиле Почему я люблю X или Почему я не люблю X. Все прекрасно понимают, что X — инструмент. Ведь нет же таких статей про лопату. Хотя, кто знает, ведь ООП существует несколько десятилетий, а лопата несколько тысяч, и быть может где-нибудь в в каменном веке шли жестокие холивары на тему, что лучше лопатка мамонта или мотыга из камня?
Зачем нужны абстракции и интерфейсы
И что это вообще такое?
Как в старом анекдоте: про объектно-ориентированное программирование можно рассказать просто и неправильно либо сложно и неправильно. Мы попробуем рассказать про очередной аспект ООП просто.
Зачем это: ООП — одна из главных концепций современной разработки. Она применима не к каким-то конкретным языкам, это скорее способ мышления в программировании. Если вы понимаете ООП, ваш код на любом языке будет чище, читаемее и эффективнее.
В этой статье разберём два сложных понятия из объектно-ориентированного программирования: абстракции и интерфейсы. Это ещё одна ступень в понимании непостижимого.
Основные идеи из ООП
Абстракция
Представьте, что вы попросили нескольких человек описать в общих чертах, что такое телефон и как им пользоваться: пусть это будут бабушка, мама и подруга. Бабушка вспомнит про дисковые телефоны и трубки с витым проводом. Мама расскажет про радиотелефоны, у которых есть база и есть трубка, с которой можно ходить по всей квартире, а подруга начнёт описывать мобильник.
Несмотря на то что рассказы будут сильно отличаться между собой, у них будет несколько общих моментов про телефон:
Получается, что если представить абстрактный телефон, то получится такое устройство с динамиком, микрофоном и средством набора номера.
Это и есть абстракция: когда мы описываем только самые существенные детали, которые важны для задачи. В нашем случае задача такая — понять, что такое телефон и как им пользоваться. Поэтому микрофон и динамик для этой задачи важен, а способ связи телефона с сетью — нет. Устройство набора номера важно, а то, какая мелодия играет при вызове — нет.
🔥 Абстракция — это когда мы сосредотачиваемся только на существенных для задачи деталях и игнорируем всё остальное. В ООП абстракция означает, что для каждого объекта мы задаём минимальное количество методов, полей и описаний, которые позволят нам решить задачу. Чем меньше характеристик, тем лучше абстракция, но ключевые характеристики убирать нельзя.
Чтобы работать с абстракциями, используют интерфейсы.
Интерфейс
Итак, у нас есть некое устройство с трубкой, микрофоном, динамиком и средством набора номера. Но если вы вспомните рассказы мамы, бабушки и подруги, то обнаружите вот что:
Всё это — интерфейсы. Они позволяют работать с объектом, не вникая в то, как он устроен внутри. Если вы умеете работать с интерфейсом номеронабирателя, то вам всё равно, нужно ли крутить диск, нажимать физические кнопки на радиотрубке или давить пальцем на сенсорный экран.
Такой интерфейс как бы говорит нам — я передам в телефон любые цифры, какие захочешь. Как я это сделаю внутри и как они будут обработаны — неважно, просто набери номер, а дальше телефон сам разберётся.
Интерфейсы — это действия над объектом, доступные другим объектам (поэтому они называются публичными).
Есть ещё инкапсулированные, то есть внутренние методы. Например, у микрофона есть публичный метод «Слушать голос», и есть внутренний метод «Преобразовать голос в электрические сигналы». С его помощью он взаимодействует с другими частями нашего абстрактного телефона. Про инкапсуляцию будет отдельный материал, потому что тема большая.
Сложная терминология
Строго говоря, интерфейсы — это не действия, а методы. Сейчас объясним.
В программировании есть операции — это простейшие действия, например, скопировать значение из одной переменной в другую.
Из простых действий составляются функции — это когда несколько операций «склеиваются» в нечто единое. Мы даём этой склейке название и получаем функцию. Например, может быть функция «проверить правильность электронного адреса», которая состоит из нескольких десятков простых операций.
На языке ООП функции, привязанные к объектам, называются методами. Просто такой термин. По сути это функции, то есть склеенные вместе операции.
Итого: метод — это набор простых действий, которые склеили в единое целое и засунули в объект.
Для чего это всё
Допустим, вы работаете в команде над большим продуктом. В таких случаях удобно разделить одну большую программу на множество мелких подпрограмм и сервисов, каждый из которых решает свою узкую задачу.
Если заранее не договориться о том, как эти компоненты обмениваются данными между собой, то может случиться то, о чём мы уже предупреждали:
Чтобы такого не было, поступают так: