Практическое применение ООП
https://stackoverflow.com/questions/1761109
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianВопрос
Недавно у меня был спор с коллегой, который не является поклонником ООП.Что привлекло мое внимание, так это то, что он сказал:
"Какой смысл делать мое кодирование в objects?Если это повторное использование, то я могу просто создать библиотеку и вызывать любые функции, которые мне нужны, для любой поставленной задачи.Нужны ли мне эти концепции полиморфизма, наследования, интерфейсов, шаблонов или чего-то еще?"
Мы работаем в небольшой компании, разрабатывающей небольшие проекты для сайтов электронной коммерции и недвижимости.
Как я могу воспользоваться преимуществами ООП в "повседневной, реальной" настройке?Или ООП действительно предназначалось для решения сложных проблем, а не для "повседневной" разработки?
Решение
Преимущества ООП заключаются в привязке набора данных к набору моделей поведения.
Итак, если вам нужно выполнить много связанных операций над связанным набором данных, вы можете написать множество функций, которые работают со структурой, или вы можете использовать объект.
Объекты дают вам некоторую помощь в повторном использовании кода в форме наследования.
IME, проще работать с объектом с известным набором атрибутов и методов, чем сохранять набор сложных структур и функций, которые работают с ними.
Некоторые люди будут продолжать говорить о наследовании и полиморфизме.Это ценно, но реальная ценность в ООП (на мой взгляд) заключается в том, что она хорошо инкапсулирует данные и связывает их с поведением.
Должны ли вы использовать ООП в своих проектах?Это зависит от того, насколько хорошо ваш язык поддерживает ООП.Это зависит от типов проблем, которые вам нужно решить.
Но, если вы создаете небольшие веб-сайты, вы все еще говорите о достаточной сложности, чтобы я использовал дизайн ООП при условии надлежащей поддержки на языке разработки.
Другие советы
Мое лично мнение:контекст
Когда вы программируете в ООП, вы лучше осознаете контекст.Это поможет вам организовать код таким образом, чтобы его было легче понять, поскольку реальный мир также объектно-ориентирован.
Больше, чем просто заставить что-то работать - точка зрения вашего друга, хорошо продуманный OO-дизайн легче понять, следовать, расширять и внедрять.Например, намного проще делегировать работу, которая категорически схожа, или хранить данные, которые должны оставаться вместе (да, даже структура C является объектом).
Что ж, я уверен, что многие люди дадут гораздо больше академически правильных ответов, но вот мой взгляд на несколько наиболее ценных преимуществ:
- ООП обеспечивает лучшую инкапсуляцию
- ООП позволяет программисту мыслить в более логичных терминах, облегчая разработку и понимание программных проектов (если они хорошо спроектированы).
- ООП - это экономия времени.Например, посмотрите на то, что вы можете сделать со строковым объектом C ++, векторами и т.д.Вся эта функциональность (и многое другое) предоставляется "бесплатно". На самом деле это функции библиотек классов, а не самой ООП, но почти все реализации ООП поставляются с хорошими библиотеками классов.Можете ли вы реализовать все это на C (или большую его часть)?Конечно.Но зачем писать это самому?
Посмотрите на использование шаблонов проектирования, и вы увидите полезность ООП.Речь идет не только об инкапсуляции и повторном использовании, но и о расширяемости и ремонтопригодности.Именно интерфейсы делают вещи мощными.
Несколько примеров:
Реализация потока (шаблона декоратора) без объектов затруднена
Добавление новой операции в существующую систему, такой как новый тип шифрования (шаблон стратегии), может быть затруднено без объектов.
Посмотрите на то, как PostgreSQL будет реализовано и Ваше бронируйте базы данных говорит, что базы данных должны быть выполнены, и вы увидите большой разница.В книге будут предложены узловые объекты для каждого оператора.Postgres использует множество таблиц и макросы, чтобы попытаться эмулировать эти узлы.Это гораздо менее красиво и намного из-за этого сложнее расширять.
Список можно продолжать.
Сила большинства языков программирования заключается в абстракциях, которые они делают доступными.Объектно-ориентированное программирование предоставляет очень мощную систему абстракций в том смысле, что она позволяет вам управлять взаимосвязями между связанными идеями или действиями.
Рассмотрим задачу вычисления площадей для произвольного и расширяющегося набора фигур.Любой программист может быстро написать функции для области круга, квадрата, треугольника и т.д.и храните их в библиотеке.Трудность возникает при попытке написать программу, которая идентифицирует и вычисляет площадь произвольной формы.Каждый раз, когда вы добавляете новый вид формы, скажем, пятиугольник, вам нужно будет обновлять и расширять что-то вроде IF или CASE структура, позволяющая вашей программе идентифицировать новую форму и вызывать правильную процедуру области из вашей "библиотеки функций".Через некоторое время расходы на техническое обслуживание, связанные с таким подходом, начинают накапливаться.
При объектно-ориентированном программировании многое из этого предоставляется бесплатно - просто определите класс Shape, который содержит метод area .Тогда на самом деле не имеет значения, с какой конкретной формой вы имеете дело во время выполнения, просто сделайте каждую геометрическую фигуру объектом, наследуемым от Shape, и вызовите метод area .Объектно-ориентированная парадигма обрабатывает детали того, нужно ли в данный момент времени, с помощью этого пользовательского ввода, вычислять площадь круга, треугольника, квадрата, пятиугольника или опции ellipse, которая была добавлена всего полминуты назад.
Что, если вы решили изменить интерфейс, лежащий в основе способа вызова функции area?При объектно-ориентированном программировании вы бы просто обновили класс Shape, и изменения автоматически распространились бы на все объекты, наследуемые от этого класса.С не объектно-ориентированной системой вы столкнулись бы с задачей пройтись по вашей "библиотеке функций" и обновить каждый отдельный интерфейс.
Таким образом, объектно-ориентированное программирование предоставляет мощную форму абстракции, которая может сэкономить ваше время и усилия за счет устранения повторений в вашем коде и оптимизации расширений и обслуживания.
Все парадигмы программирования преследуют одну и ту же цель:скрытие ненужной сложности.
Некоторые проблемы легко решаются с помощью императивной парадигмы, подобной той, которую использует ваш друг.Другие проблемы легко решаются с помощью объектно-ориентированной парадигмы.Есть много других парадигмы.Основные из них (логическое программирование, функциональное программирование и императивное программирование) эквивалентны друг другу;объектно-ориентированное программирование обычно рассматривается как расширение императивного программирования.
Объектно-ориентированное программирование лучше всего использовать, когда программист моделирует элементы, которые похожи, но не одно и то же.Императивная парадигма объединила бы различные виды моделей в одну функцию.Объектно-ориентированная парадигма разделяет различные виды моделей на различные методы для связанных объектов.
Ваш коллега, похоже, застрял в одной парадигме.Удачи.
Примерно в 1994 году я пытался разобраться в ООП и С ++ одновременно и обнаружил, что разочарован, хотя в принципе мог понять, в чем ценность ООП.Я так привык к возможности изменять состояние любой части приложения с других языков (в основном Basic, Assembly и языков семейства Pascal), что казалось, будто я отказываюсь от производительности в пользу какой-то академической абстракции.К сожалению, мои первые несколько встреч с OO-фреймворками, такими как MFC, упростили взлом, но не обязательно дали много информации на пути к просветлению.
Только благодаря сочетанию настойчивости, использованию альтернативных (не C ++) способов работы с объектами и тщательному анализу OO-кода, который 1) работал и 2) читался более связно и интуитивно, чем эквивалентный процедурный код, я начал по-настоящему понимать это.И 15 лет спустя я регулярно удивляюсь новым (для меня) открытиям умных, но впечатляюще простых OO-решений, которые я не могу представить, чтобы они выполнялись так же аккуратно при процедурном подходе.
Последние пару лет я проходил через те же трудности, пытаясь разобраться в парадигме функционального программирования.Перефразируя Пола Грэма, когда вы смотрите на континуум власти, вы видите все, чего не хватает.Когда вы просматриваете континуум власти, вы не видите власти, вы просто видите странность.
Я думаю, чтобы взять на себя обязательство делать что-то по-другому, вы должны 1) увидеть, что кто-то явно более продуктивен с более мощными конструкциями, и 2) отбросить недоверие, когда вы обнаружите, что упираетесь в стену.Вероятно, полезно иметь наставника, который тоже, по крайней мере, немного продвинулся в своем понимании новой парадигмы.
За исключением смекалки, необходимой для приостановки неверия, если вы хотите, чтобы кто-то быстро оценил ценность модели OO, я думаю, вы могли бы поступить намного хуже, чем попросить кого-то провести неделю с книгой Pragmatic Programmers о Rails.К сожалению, в нем упущено много деталей о том, как работает магия, но это довольно хорошее введение в мощь системы OO-абстракций.Если после работы с этой книгой ваш коллега по какой-то причине по-прежнему не видит ценности OO, возможно, он / она безнадежен.Но если они готовы потратить немного времени на работу с подходом, который имеет сильно самоуверенный OO-дизайн, который работает и выводит их из 0-60 намного быстрее, чем выполнение того же самого на процедурном языке, возможно, есть надежда.Я думаю, это верно, даже если ваша работа не связана с веб-разработкой.
Я не уверен, что упоминание "реального мира" было бы таким же преимуществом, как рабочая среда для написания хороших приложений, потому что оказывается, что, особенно в статически типизированных языках, таких как C # и Java, моделирование реального мира часто требует сложных абстракций.Вы можете увидеть конкретный пример сложности моделирования реального мира, посмотрев на тысячи людей, пытающихся смоделировать что-то столь же якобы простое, как геометрическая абстракция "форма" (shape, эллипс, круг).
Для меня сила ООП не проявляется до тех пор, пока вы не начнете говорить о наследовании и полиморфизме.
Если чей-то аргумент в пользу ООП основывается на концепции инкапсуляции и абстракции, что ж, для меня это не очень убедительный аргумент.Я могу написать огромную библиотеку и документировать к ней только те интерфейсы, о которых я хочу, чтобы пользователь знал, или я могу полагаться на конструкции языкового уровня, такие как пакеты в Ada, чтобы сделать поля закрытыми и предоставлять только то, что я хочу предоставить.
Однако реальное преимущество приходит, когда я пишу код в общей иерархии, чтобы его можно было повторно использовать позже, так что одни и те же точные интерфейсы кода используются для разных функциональных возможностей для достижения одного и того же результата.
Почему это удобно?Потому что я могу стоять на плечах гигантов, чтобы выполнить свою текущую задачу.Идея заключается в том, что я могу свести части проблемы к самым базовым частям, объектам, которые составляют объекты, которые составляют...объекты, из которых состоит проект.Используя класс, который очень хорошо определяет поведение в общем случае, я могу использовать тот же проверенный код для создания более конкретной версии того же самого, а затем более конкретной версии того же самого, а затем еще более конкретной версии того же самого.Ключевым моментом является то, что каждая из этих сущностей имеет общность, которая уже была закодирована и протестирована, и нет необходимости повторно внедрять ее позже.Если я не использую наследование для этого, я в конечном итоге переопределяю общую функциональность или явно связываю свой новый код со старым кодом, что предоставляет мне сценарий для внесения ошибок потока управления.
Полиморфизм очень удобен в случаях, когда мне нужно добиться определенной функциональности от объекта, но такая же функциональность также необходима от похожих, но уникальных типов.Например, в Qt есть идея вставлять элементы в модель, чтобы данные могли отображаться, и вы могли легко поддерживать метаданные для этого объекта.Без полиморфизма мне пришлось бы утруждать себя гораздо большим количеством деталей, чем я делаю в настоящее время (Т.е.мне нужно было бы реализовать те же интерфейсы кода, которые используют ту же бизнес-логику, что и элемент, который изначально предназначался для использования в модели).Поскольку базовый класс моего объекта, связанного с данными, изначально взаимодействует с моделью, я могу вместо этого без проблем вставить метаданные в эту модель.Я получаю то, что мне нужно из объекта, не заботясь о том, что нужно модели, и модель получает то, что ей нужно, не заботясь о том, что я добавил в класс.
Попросите своего друга визуализировать Любой объект в самой его Комнате, Доме или Городе...и если он может указать одному такому объекту, который сам по себе является системой и способен выполнять какую-то значимую работу.
Такие вещи, как кнопка, не делают что-то сами по себе - для совершения телефонного звонка требуется множество объектов.
Точно так же автомобильный двигатель состоит из коленчатого вала, поршней, свечей зажигания.Концепции OOPS развились из нашего восприятия естественных процессов или вещей в нашей жизни.
Книга "Inside COM" рассказывает о назначении COM, проводя аналогию с детской игрой по распознаванию животных с помощью вопросов.
Дизайн превосходит технологию и методологию.Хорошие проекты, как правило, включают универсальные принципы управления сложностью, такие как закон Деметры, который лежит в основе того, что функции языка OO стремятся кодифицировать.
Хороший дизайн не зависит от использования специфических языковых функций OO, хотя обычно их использование отвечает наилучшим интересам пользователя.
Это не только делает
- программирование проще / более ремонтопригодно в текущей ситуации для других людей (и для вас самих)
- Это уже позволяет упростить операции CRUD с базой данных (Создание, обновление, удаление).
Вы можете найти более подробную информацию об этом, просмотрев:- Java - Язык :Переход в спящий режим - Точечная сеть :Структура сущности
Посмотрите даже, как LINQ (Visual Studio) может значительно упростить вашу жизнь при программировании.
- Кроме того, вы можете начать использовать шаблоны проектирования для решения реальных жизненных проблем (все шаблоны проектирования связаны с OO).
Возможно, это даже забавно продемонстрировать с помощью небольшой демонстрации:
- Допустим, вам нужно аналогичным образом сохранить сотрудников, учетные записи, участников, книги в текстовом файле.
.PS.Я попытался написать это ПСЕВДО-способом :)
способ ОО
Код, который вы вызываете:ввод-вывод.файл.сохранить(objectsCollection.ourFunctionForSaving())
коллекция объектов класса
функция ourFunctionForSaving() В виде строки
Строка _Objects ( Объекты )
for each _Object in objectsCollection
Objects &= _Object & "-"
end for
возвращает _Objects метод завершения
НЕ-OO Способ
Я не думаю, что буду записывать код, отличный от oo.Но подумайте об этом :)
ТЕПЕРЬ ДАВАЙТЕ СКАЖЕМ
В смысле ОО.Приведенный выше класс является родительским классом всех методов для сохранения книг, сотрудников, участников, учетных записей...Что произойдет, если мы захотим изменить способ сохранения в текстовый файл?Например, чтобы сделать его компактным в соответствии с текущим стандартом (.CVS).
И давайте предположим, что мы хотели бы добавить функцию загрузки, сколько кода вам нужно написать?В OO-способе вам нужен только метод add a New Sub, который может разбить все данные на параметры (это происходит один раз).
Пусть ваш коллега подумает об этом :)
В доменах, где состояние и поведение плохо согласованы, объектная ориентация снижает общую плотность зависимостей (т.е.сложность) в пределах этих областей, что делает результирующие системы менее хрупкими.
Это происходит потому, что сущность объектно-ориентированный подход основан на том факте, что с организационной точки зрения он вообще не проводит различия между состоянием и поведением, рассматривая оба одинаково как "особенности".Объекты - это просто наборы объектов, сгруппированных для минимизации в целом зависимость.
В других областях объектная ориентация - не самый лучший подход.Существуют разные языковые парадигмы для разных проблем.Опытные разработчики знают это и готовы использовать любой язык, наиболее близкий к предметной области.
