Практическое использование ООП

Question

У меня недавно была дискуссия с коллегой, который не фанат ООП . Мое внимание привлекло то, что он сказал:

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

Мы в небольшой компании, разрабатывающей небольшие проекты для сайтов электронной коммерции и недвижимости.

Как я могу воспользоваться преимуществами ООП в «повседневной, реальной» обстановке? Или ООП действительно предназначалось для решения сложных проблем и не предназначено для «повседневной» разработки?

Answer 1

Мой личный взгляд: контекст

Когда вы программируете в ООП, вы лучше понимаете контекст. Это помогает вам организовать код таким образом, чтобы его было легче понять, потому что реальный мир также является объектно-ориентированным.

Answer 2

Преимущества ООП заключаются в привязке набора данных к набору поведения.

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

Объекты дают вам некоторую помощь в повторном использовании кода в форме наследования.

IME, легче работать с объектом с известным набором атрибутов и методов, так как он должен содержать набор сложных структур и функций, которые над ними работают.

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

Должны ли вы использовать ООП в своих проектах? Это зависит от того, насколько хорошо ваш язык поддерживает ООП. Это зависит от типов проблем, которые вам нужно решить.

Но если вы работаете с небольшими веб-сайтами, вы все еще говорите о достаточной сложности, чтобы я мог использовать ООП-дизайн при надлежащей поддержке языка разработки.

Answer 3

Больше, чем просто заставить что-то работать - точка зрения вашего друга, хорошо спроектированный ОО-проект легче понять, следовать, расширять, расширять и внедрять. Например, намного проще делегировать работу, которая категорически похожа, или хранить данные, которые должны оставаться вместе (да, даже структура C является объектом).

Answer 4

Ну, я уверен, что многие люди дадут намного более академически правильные ответы, но вот мое мнение о некоторых из наиболее ценных преимуществ:

• ООП обеспечивает лучшую инкапсуляцию
• ООП позволяет программисту мыслить более логично, облегчая разработку и понимание программных проектов (если они хорошо спроектированы)
• ООП экономит время. Например, посмотрите, что вы можете делать со строковым объектом C ++, векторами и т. Д. Все эти функции (и многое другое) предоставляются бесплатно. Теперь это действительно функции библиотек классов, а не самого ООП, но почти все реализации ООП поставляются с хорошими библиотеками классов. Можете ли вы реализовать все эти вещи в C (или большинство из них)? Конечно. Но зачем писать самому?

Answer 5

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

Рассмотрим задачу вычисления площадей для произвольной и расширяющейся коллекции фигур. Любой программист может быстро написать функции для области круга, квадрата, треугольника и т. Д. и хранить их в библиотеке. Трудность возникает при попытке написать программу, которая идентифицирует и вычисляет площадь произвольной формы. Каждый раз, когда вы добавляете новый тип фигуры, скажем, пятиугольник, вам нужно будет обновлять и расширять что-то вроде структуры IF или CASE, чтобы позволить вашей программе идентифицировать новую форму и вызывать правильную подпрограмму области из вашего " библиотека функций ". Через некоторое время затраты на обслуживание, связанные с этим подходом, начинают накапливаться.

В объектно-ориентированном программировании многое из этого бесплатное - просто определите класс Shape, который содержит метод области. Тогда не имеет значения, с какой конкретной формой вы имеете дело во время выполнения, просто сделайте каждую геометрическую фигуру объектом, которая наследуется от Shape, и вызовите метод area. Объектно-ориентированная парадигма обрабатывает детали того, нужно ли в данный момент времени, с этим пользовательским вводом, вычислять площадь круга, треугольника, квадрата, пятиугольника или эллипса, который был добавлен только полминуты назад.

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

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

Answer 6

Посмотрите на использование шаблонов проектирования, и вы увидите полезность ООП. Это не просто инкапсуляция и повторное использование, но расширяемость и ремонтопригодность. Это интерфейсы, которые делают вещи мощными.

Несколько примеров:

• Реализация потока (шаблона декоратора) без объектов трудна

• Добавление новой операции в существующую систему, такой как новый тип шифрования (шаблон стратегии), может быть затруднено без объектов.

• Посмотрите, как работает PostgresQL реализовано по сравнению с тем, как ваш Книга базы данных говорит, что база данных должна будут реализованы, и вы увидите большой разница. Книга предложит узловые объекты для каждого оператора. Postgres использует множество таблиц и макросы, чтобы попытаться эмулировать эти узлы. Это гораздо менее красиво и намного из-за этого труднее расширяться.

Список можно продолжить.

Answer 7

Мне кажется, что сила ООП не проявляется, пока вы не начнете говорить о наследовании и полиморфизме.

Если аргумент в пользу ООП основывается на концепции инкапсуляции и абстракции, то для меня это не очень убедительный аргумент. Я могу написать огромную библиотеку и задокументировать только те интерфейсы, о которых должен знать пользователь, или я могу полагаться на конструкции уровня языка, такие как пакеты в Ada, чтобы сделать поля приватными и раскрыть только то, что я хочу разоблачить.

Однако реальное преимущество приходит, когда я написал код в общей иерархии, чтобы впоследствии его можно было повторно использовать, чтобы одни и те же интерфейсы точного кода использовались для разных функций для достижения того же результата.

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

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

Answer 8

Примерно в 1994 году я пытался разобраться в ООП и С ++ одновременно и обнаружил, что разочарован, хотя в принципе я мог понять, какова ценность ООП. Я был настолько привык к тому, что мог связываться с состоянием любой части приложения из других языков (в основном базового, ассемблера и языков семейства Паскаль), что казалось, что я отказался от продуктивности в пользу какой-то академической абстракции. К сожалению, мои первые несколько встреч с OO-фреймворками, такими как MFC, облегчили взлом, но не обязательно обеспечили много просветления.

Только благодаря комбинации настойчивости, альтернативных (не-C ++) способов работы с объектами и тщательного анализа ОО-кода оба: 1) работали и 2) читали более связно и интуитивно, чем эквивалентный процедурный код что я начал действительно понимать это. И 15 лет спустя я регулярно удивляюсь новым (для меня) открытиям умных, но впечатляюще простых ОО-решений, которые я не могу себе представить, делая их аккуратно в процедурном подходе.

За последние пару лет я проходил ту же борьбу, пытаясь разобраться в парадигме функционального программирования. Перефразируя Пола Грэма, когда вы смотрите вниз на континуум силы, вы видите все, чего не хватает. Когда вы смотрите на континуум силы, вы не видите силу, вы просто видите странность.

Я думаю, что для того, чтобы совершить что-то по-другому, вы должны: 1) увидеть кого-то, очевидно, более продуктивного с более мощными конструкциями, и 2) приостановить неверие, когда вы столкнетесь с ударом по стене. Вероятно, это помогает иметь наставника, который, по крайней мере, чуть-чуть дальше в их понимании новой парадигмы.

Если исключить сомнение, необходимое для приостановки неверия, если вы хотите, чтобы кто-то быстро ухватился за ценность модели ОО, я думаю, вы могли бы сделать намного хуже, чем попросить кого-то провести неделю с книгой прагматических программистов на Rails. К сожалению, в нем не раскрываются многие детали того, как работает магия, но это довольно хорошее знакомство с мощью системы абстракций ОО. Если, поработав над этой книгой, ваш коллега по какой-то причине все еще не видит значения ОО, он может оказаться безнадежным. Но если они готовы потратить немного времени на работу с подходом, который имеет сильно выраженный дизайн ОО, который работает и получает их от 0 до 60 гораздо быстрее, чем делает то же самое на процедурном языке, то может быть только надежда. Я думаю, что это правда, даже если ваша работа не связана с веб-разработкой.

Я не уверен, что создание "реального мира" будет таким же коммерческим аргументом, как рабочая среда для написания хороших приложений, потому что оказывается, особенно в статически типизированных языках, таких как C # и Java, моделирование реальный мир часто требует извилистых абстракций. Вы можете увидеть конкретный пример сложности моделирования реального мира, если взглянуть на тысячи людей, пытающихся смоделировать что-то столь же якобы простое, как геометрическая абстракция формы (форма, эллипс, круг).

Answer 9

Все парадигмы программирования имеют одну и ту же цель: скрыть ненужную сложность.

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

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

Ваш коллега, похоже, застрял в одной парадигме. Удачи.

Answer 10

Попросите вашего друга визуализировать любой объект в его самой Комнате, Доме или Городе ... и может ли он сказать одному такому объекту, что система сама по себе и способна выполнять какую-то значимую работу.

Такие вещи, как кнопка, не делают что-то в одиночку - для звонка требуется много объектов.
Аналогичным образом автомобильный двигатель состоит из коленчатого вала, поршней, свечей зажигания. Концепции OOPS возникли из нашего восприятия природных процессов или вещей в нашей жизни.

Книга "Inside COM" рассказывает о цели COM, взяв аналогию из детской игры идентификации животных, задавая вопросы.