Когда мы на самом деле используем объектно-ориентированное программирование? [закрыто]

35

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

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

Еще немного информации о том, что должно быть сделано:

  • анализировать .csvфайл и обрабатывать данные на основе файла конфигурации (столбцы могут быть разными - например, по количеству столбцов или данных, которые они содержат)
  • использовать обработанные выше данные для создания новых пользовательских форматированных данных (или нескольких файлов на основе некоторых из вышеуказанных значений)
  • используйте последние отформатированные данные для создания файла XML.
  • разбить файл XML на несколько XMLсек в зависимости от их содержания
  • приложение должно быть на основе CLI
  • Есть, конечно, другие вещи, такие как: регистрация некоторых событий, анализ аргументов CLI и так далее.

Теперь это совсем не большое / сложное приложение, и оно также почти закончено, но в течение всего процесса разработки я постоянно спрашивал себя, следует ли это делать с использованием ООП или нет.

Итак, мой вопрос будет таким: как вы, ребята, знаете / решаете, когда использовать ООП в приложении?

Грайдеану Алекс.
источник
12
Re: «Клиент ... не заботится о коде, он просто хочет, чтобы все было сделано». Хорошо, тогда сделай это. Но насколько сложна эта вещь? Насколько хорошо вы действительно понимаете требования? Насколько вероятно, что клиент когда-нибудь позже попросит вас изменить вещь? Иногда все, что вам нужно, - это быстрый и грязный хак, но чем больше времени и энергии вы собираетесь в него инвестировать, тем более вероятно, что какой-то структурированный подход к решению проблемы (например, проектирование ОО) принесет вам пользу.
Соломон Слоу
5
Не используйте «РЕДАКТИРОВАТЬ» или другие подобные названия в своих сообщениях. Каждый пост Stack Exchange имеет подробную историю изменений, которую может просмотреть каждый. Такая информация, как «Я не спрашивал, что такое ООП», в любом случае более уместна в комментарии, а не в вашем вопросе.
Роберт Харви
@RobertHarvey хорошо, понял. Я сделаю это в следующий раз.
Грайдеану Алекс.

Ответы:

60

Python - это мультипарадигмальный язык, который означает, что вы можете выбрать парадигму, наиболее подходящую для данной задачи. Некоторые языки, такие как Java, являются ОО с одной парадигмой, что означает, что вы будете испытывать головную боль, если попытаетесь использовать любую другую парадигму. Плакаты с надписью «всегда используйте ОО», вероятно, происходят из такого языка. Но, к счастью, у вас есть выбор!

Я отмечаю, что ваша программа является приложением CLI, которое читает некоторые входные данные (файлы csv и config) и производит некоторые выходные данные (файлы xml), но не является интерактивным и, следовательно, не имеет GUI или API с сохранением состояния. Такая программа естественным образом выражается как функция от ввода до вывода, которая делегирует другим функциям подзадачи.

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

OO имеет еще одно преимущество в том, что полиморфизм позволяет использовать более слабосвязанную архитектуру, в которой различные реализации одного и того же интерфейса могут быть легко заменены. В сочетании с внедрением зависимостей это может позволить загрузку зависимостей и других полезных вещей на основе конфигурации. Это в основном подходит для очень больших приложений, хотя. Для программы размером с то, что вы описываете, это будет очень много накладных расходов без видимой выгоды.

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

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

JacquesB
источник
8
Наконец-то хорошо сбалансированный ответ, который не просто воспевает похвалу ООП :-)
cmaster
1
Такой ответ я ожидал. Не могли бы вы немного расширить свой ответ? Это выглядит потрясающе до сих пор.
Грайдеану Алекс.
3
@ Декстер: Чем ты. Какую дополнительную информацию вы ищете?
JacquesB
3
Я бы добавил к этому, что функциональное программирование может быть парадигмой, на которой можно продолжить чтение.
Эндрю говорит восстановить Монику
1
@Bergi: Да, это преимущество мультипарадигмального языка. Вы можете использовать библиотеки OO без необходимости писать свою собственную программу в стиле OO.
JacquesB
15

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

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

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

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

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

Дэвид Арно
источник
6

Объектно-ориентированное программирование добавляет в ваш арсенал четыре новых инструмента :

  1. Инкапсуляция
  2. абстракция
  3. наследование
  4. Полиморфизм

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

Роберт Харви
источник
18
Абстракция и полиморфизм являются инструментами, предоставляемыми многими «ориентациями» программирования. ООП на самом деле предлагает более слабую форму инкапсуляции, чем другие подходы, потому что наследование поощряет проекты с утечкой абстракции. Единственное, что ООП действительно добавляет в инструментарий, это наследование, которое широко рассматривается как плохая вещь.
Дэвид Арно
4
@DavidArno: Вы в основном говорите: «Никогда не используйте ООП».
Роберт Харви
6
Это уже позади тяжелого рабочего дня, посвященного изучению кода других людей, прямая процедурная реализация программы часто лучше, чем реализация с плохим пониманием ОО-дизайна. Архитектура ОО может быть очень мощной, но должна использоваться как специя в кулинарии, с экспертными знаниями и только нужным количеством. Неправильное использование ОО-дизайна встречается так же часто, как просить кетчуп в плохом ресторане.
Филл
6
Ни один из четырех инструментов (инкапсуляция, абстракция, наследование, полиморфизм) не является специфическим для ООП. Возможно, вам следует объяснить, как ООП отличается от других парадигм по отношению к этим измерениям.
Джорджио
4
@gardenhead, ваше странное чувство превосходства ничего не делает для вашей должности. Возможно, вам следует задать вопрос под названием «Почему наиболее подходящие языки часто являются ОО?» А еще лучше, Ctrl + F и введите «GUI».
Гусдор
1

Этот вопрос мне кажется немного запутанным. Если вы пишете это на Python, вы наверняка собираетесь использовать объекты. Когда вы открываете файл, он возвращает объект. Когда вы даете результат, он возвращает Object итератора. Каждая созданная вами функция является объектом. Ставить под сомнение значение ОО в приложениях Python, по меньшей мере, странно.

Основываясь на комментариях здесь, да, Python поддерживает функциональные парадигмы, но он в основном основан на объектах. Сам язык и встроенные библиотеки ориентированы вокруг объектов. Да, он поддерживает лямбду (как и Java и любое другое количество языков, обычно описываемых как ОО), но он намеренно упрощен по сравнению с настоящим функциональным языком.

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

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

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

JimmyJames
источник
5
да, объекты не равны ООП. есть различие между наличием объекта и структурированием вашей архитектуры вокруг объектов и их взаимодействий. вроде как, если вы делаете функцию, которая не означает, что вы занимаетесь функциональным программированием.
Сара
Вы можете довольно легко считать объект Python / JavaScript записью, которая довольно функциональна. Функциональные языки имеют объекты. Ключ во втором слове: ориентированный. Языки ООП полностью ориентированы на использование объектов, в то время как некоторые другие языки кажутся просто частью вашего набора инструментов.
Дэн Пантри
0

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

Много раз я вижу объект, я вижу методы, но я также вижу, что движущей силой кода является поток, а не состояние.

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

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

И хорошо, что вы можете проверить это.

Питер Б
источник
3
Ваш пример чтения файла с диска или чтения файла из Интернета также может быть реализован с различными функциями. Вам не нужно ОО для этого.
JacquesB
0

С точки зрения непрофессионала:

  • Вы можете использовать ООП или не ООП в любых проектах, которые вы хотите.
  • ООП не панацея, но она помогает справиться со сложностью.
  • Это выходит за рамки модульности, речь идет о разделении. Подумайте о различных отсеках корабля для сохранения плавучести, если корпус поврежден.
  • ООП - это способ управления зависимостями, поэтому ошибки можно легче отследить, поскольку существует только определенный набор способов, которыми разные компоненты программы могут сообщать друг другу.
  • В программе работает много вещей: переменные, константы, методы, файлы, параметры, функции, модули и т. Д. Они могут взаимодействовать друг с другом способами, которые иногда могут быть непредсказуемыми. ООП - это набор принципов, которые уменьшают количество способов взаимодействия вещей друг с другом. Вы не обязаны использовать ООП для этого, но это помогает.

Тем не менее, есть и другие факторы, которые необходимо учитывать:

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

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

Но...

Если ваша команда не имеет опыта в ООП / ООД и не имеет опыта в этой области, используйте имеющиеся у вас ресурсы.

Тулаинс Кордова
источник
-2

Итак, мой вопрос будет таким: как вы, ребята, знаете / решаете, когда использовать ООП в приложении?

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

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

  • журналирование, в качестве примера, потому что это позволяет легко заменить другой регистратор

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

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

Эрик Эйдт
источник
6
Я не понизил (хотя я был близок к этому), но я думаю, что это причина того, что вы получили отрицательные голоса: «Всегда используйте это, потому что это здорово» - редко хороший совет. Всегда есть исключения. Ни один инструмент не обходится без недостатков, и ООП не является исключением. Скажите людям, что это хорошо, скажите людям, для чего это хорошо, скажите людям, почему это хорошо, скажите людям избегать альтернатив, если они могут, но никогда не говорите людям не думать об альтернативах.
cмейстер
@cmaster, я в порядке, если люди понижают голос, это их выбор, и я тоже это сделал. Что касается предмета, я все еще думаю, что это правильный ответ для человека, задающего вопрос; ИМХО, ОП нужно полностью перейти и использовать ООП, вместо того, чтобы пытаться решить, когда использовать ООП, и иногда делать выбор в создании класса, а в противном случае писать процедурный код.
Эрик Эйдт
2
@cmaster Я могу оценить совет Эрика. Поскольку ответ «все зависит» может быть политически корректным, давайте посмотрим правде в глаза, ОО в значительной степени стали основой для программных сред, которые его поддерживают. Так что давайте не будем себя обманывать, вы вряд ли ошибетесь с OO. Описанный скрипт, хотя и линейный, достаточно сложный, чтобы объекты могли принести вам некоторую пользу.
Мартин Маат
2
@ErikEidt «ОП должен прыгнуть полностью и использовать ООП». Вы можете перефразировать это как «ОП должен перестать думать о лучшем способе решения проблемы клиента и просто следовать Единому Истинному Пути к Просветлению». К сожалению, я должен был иметь дело с большим количеством так называемых компьютерных профессионалов , которые делают следовать этой методологии проектирования программного обеспечения. Обязательный мультфильм Дилберта: dilbert.com/strip/1996-02-27
alephzero
1
Я думаю, что есть что-то, что можно сказать о том, что мы на 100% впитываем что-то, чтобы действительно усвоить и поглотить это. не так, что вы можете использовать его каждый день до конца своей жизни, но вы действительно УЧИТЕ сильные и слабые стороны, а не просто читаете о них. Я бы порекомендовал любому, кто потратит несколько месяцев на хардкорную ООП и несколько месяцев на хардкорную FP (как у haskell) и несколько месяцев на процедурный C и так далее. просто иди туда и пачкайся этим.
Сара
-2

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

Как - Это часть работы с фреймами вашего кода, где вы создаете некую абстракцию, решаете, как ваши блоки работают в целом и как они взаимодействуют с другими блоками.

Что делать - в этой части блоки выполняют саму работу. Здесь классы являются производными от базовых классов, созданных в разделе «Как разделить».

Можно очень извлечь выгоду из OOPS

  1. если вы можете повторно использовать существующую среду и вам нужно только реализовать конкретные детали в разделе «что делать».
  2. Функциональность, которая реализуется для текущего проекта, является общей / обычно используемой, и другие проекты / будущие проекты могут извлечь выгоду из структуры, которая создается при разработке текущего проекта.
  3. Разбиение огромных проектов на общеизвестные шаблоны для решения большой проблемы.
  4. Используйте OOPS даже для небольшого проекта, чтобы привыкнуть к нему, и будьте готовы к появлению 1–3 типов проблем.
Рахул Менон
источник
То есть, вы говорите, что всегда должны использовать ООП, независимо от того, какую задачу вы хотите решить?
JacquesB
Нет :), существует множество программных паграмм, и некоторые из них пригодны для решения определенной проблемы лучше, чем другие. OOPS ни в коем случае не является лучшим решением для всех, но OOPS довольно популярно. для создания хорошего класса и структур в OOPS потребуются время и практика, поэтому, если вы хотите эффективно использовать OOPS, лучше начать с небольших проектов. Как только вы овладеете им, это полностью зависит от вас. Я рассматриваю концепции OOPS как инструмент для построения фреймворка.
Рахул Менон