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