Алгоритмы описывают, что должен делать компьютер. Структура описывает, как алгоритм изложен [в исходном коде]. ООП - это стиль программирования, который использует определенные «объектно-ориентированные» структуры.
Книги по алгоритмам часто избегают ООП, потому что они сосредоточены на алгоритме, а не на структуре. Фрагменты кода, которые в значительной степени опираются на структуру, являются плохими примерами для размещения в книге алгоритмов. Аналогично, ООП книги часто избегают алгоритмов, потому что они загромождают историю. Преимущество ООП заключается в его плавности, и привязка к алгоритму делает его более жестким. Это больше о фокусе книги, чем что-либо еще.
В реальном коде вы будете использовать оба бок о бок. Вы не можете решить компьютерные проблемы без алгоритмов по определению, и вам будет сложно писать хорошие алгоритмы без структуры (ООП или иным образом).
В качестве примера того, где они размываются, возьмем динамическое программирование. В книге по алгоритмам вы опишете, как получить однородный набор данных в массиве и использовать динамическое программирование для достижения решения. В книге ООП вы можете встретить такую структуру, как Visitor, которая позволяет создавать произвольные алгоритмы для множества разнородных объектов. Пример книги DP можно представить как очень простого посетителя, работающего с объектами в порядке снизу вверх. Шаблон Visitor можно рассматривать как скелет проблемы DP, но при этом не хватает мяса и картофеля. В действительности вы часто обнаружите, что вам часто нужно и то и другое вместе: вы используете шаблон Visitor для работы с неоднородностью по всему набору данных (в этом DP плохо), и вы используете DP в структуре Visitor, чтобы организовать свой алгоритм для минимизации времени выполнения (Visitor Безразлично»
Мы также видим алгоритмы, работающие поверх шаблонов проектирования. Трудно произносить примеры в небольшом пространстве, но когда у вас есть структура, вы начинаете хотеть манипулировать этой структурой и используете для этого алгоритмы.
Существуют ли проблемы, которые могут быть представлены и решены только ООП?
На этот вопрос сложнее ответить, чем вы думаете. Для первого порядка нет вычислительной причины, по которой вам нужно ООП для решения любой проблемы. Простым доказательством является то, что каждая ООП-программа компилируется до ассемблера, который явно не является ООП-языком.
Тем не менее, в более широком плане, ответ начинает стесняться в сторону да. Вы редко ограничены просто компьютерными методологиями. В большинстве случаев есть такие вещи, как бизнес-потребности и навыки разработчика, которые учитываются в уравнении. Многие приложения сегодня не могут быть написаны без ООП, не потому, что ООП каким-то образом является фундаментальным для этой задачи, а потому, что структура, предоставляемая ООП, была необходима для поддержания проекта в нужном русле и в рамках бюджета.
Это не означает, что в будущем мы никогда не откажемся от ООП из-за какой-то забавной новой структуры. Это просто говорит о том, что это один из самых эффективных инструментов в нашем наборе инструментов для удивительно большой части задач программирования сегодня. Будущие проблемы могут побудить нас подойти к разработке с использованием различных структур. Во-первых, я ожидаю, что нейронные сети потребуют совершенно другого подхода к разработке, который может оказаться или не оказаться «объектно-ориентированным».
Я не вижу исчезновения ООП в ближайшем будущем из-за того, как думают разработчики алгоритмов. На сегодняшний день обычным примером является то, что кто-то разрабатывает алгоритм, который не использует ООП. Сообщество ООП понимает, что алгоритм не совсем соответствует структуре ООП, и на самом деле в этом нет необходимости, поэтому они оборачивают весь алгоритм в структуру ООП и начинают его использовать. Посмотрим boost::shared_ptr. Алгоритмы подсчета ссылок, которые shared_ptrлежат внутри , не очень удобны для ООП. Однако шаблон не стал популярным до тех пор, пока shared_ptrвокруг него не была создана оболочка ООП, раскрывающая возможности алгоритмов в структурированном формате ООП. Теперь он настолько популярен, что превратил его в новейшую спецификацию для C ++, C ++ 11.
Почему это так успешно? Алгоритмы хороши в решении проблем, но они часто требуют значительных начальных инвестиций в исследования, чтобы понять, как их использовать. Объектно-ориентированная разработка очень эффективна для обертывания таких алгоритмов и обеспечения интерфейса, который требует меньших начальных вложений для обучения.