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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Но...

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

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

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

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

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

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

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

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

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

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

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

1. если вы можете повторно использовать существующую среду и вам нужно только реализовать конкретные детали в разделе «что делать».
2. Функциональность, которая реализуется для текущего проекта, является общей / обычно используемой, и другие проекты / будущие проекты могут извлечь выгоду из структуры, которая создается при разработке текущего проекта.
3. Разбиение огромных проектов на общеизвестные шаблоны для решения большой проблемы.
4. Используйте OOPS даже для небольшого проекта, чтобы привыкнуть к нему, и будьте готовы к появлению 1–3 типов проблем.