Для C / C ++, когда выгодно не использовать объектно-ориентированное программирование?

Question

Я всегда пытаюсь вписать все в методологию ООП, когда я пишу код на C / C ++. Но я понимаю, что мне не всегда нужно все навязывать. Каковы некоторые плюсы / минусы использования ООП-методологии по сравнению с нет? Меня больше интересуют плюсы и минусы НЕ использования ООП (например, есть ли преимущества оптимизации, если не использовать ООП?). Спасибо, дайте мне знать.

Answer 1

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

---

Когда не использовать ООП:

• Помещение квадратных колышков в круглые отверстия: Не заворачивайте все в классы, когда они не нужны. Иногда в этом нет необходимости, и дополнительные издержки просто делают ваш код медленнее и сложнее.
• Состояние объекта может быть очень сложным: Есть действительно хорошая цитата Джо Армстронга , который изобрел Эрланга:

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

• Ваш код уже не ООП: Не стоит переносить ваш код, если ваш старый код не ООП. Есть цитата из Ричарда Столлмана в 1995

Добавление ООП в Emacs явно не является улучшение; Я использовал ООП при работе в оконных системах Lisp Machine, и я не согласен с обычным мнением что это превосходный способ программирования.

• Переносимость с C: Вам может понадобиться экспортировать набор функций в C. Хотя вы можете имитировать ООП в C, создав структуру и набор функций, первый параметр которого получает указатель на эту структуру. это не всегда естественно.

Вы можете найти больше причин в этой статье под названием Bad Engineering Properties объектно-ориентированных языков .

На странице объектно-ориентированного программирования Википедии также обсуждаются некоторые плюсы и минусы.

Answer 2

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

Скотт Мейерс, один из гуру C ++, на самом деле утверждает против в этой статье:

Как функции, не являющиеся членами, улучшают инкапсуляцию .

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

Основываясь на опыте предыдущего крупного проекта, я полностью с ним согласен.

Answer 3

Преимущество неоперационной функциональности заключается в том, что она часто упрощает экспорт вашей функциональности на разные языки. Например, простую DLL, содержащую только функции, гораздо проще использовать в C #, вы можете использовать P / Invoke для простого вызова функций C ++. Так что в этом смысле он может быть полезен для написания чрезвычайно критичных ко времени алгоритмов, которые хорошо вписываются в один / несколько вызовов функций.

Answer 4

Ну, есть несколько альтернатив. Код не-ООП в C ++ может быть:

• процедурный код в стиле C или
• C ++ - стиль общего программирования

Единственными преимуществами первого являются простота и обратная совместимость. Если вы пишете небольшое тривиальное приложение, то возиться с классами - это просто пустая трата времени. Если вы пытаетесь написать «Hello World», просто позвоните printf уже. Не беспокойтесь об этом в классе. И если вы работаете с существующей базой кода C, она, вероятно, не является объектно-ориентированной, и попытка заставить ее использовать другую парадигму, чем она уже использует, - просто рецепт боли.

Для последнего ситуация иная, поскольку этот подход часто превосходит над "традиционным ООП".

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

ООП - немного больше, чем старое модное слово. Методология, которую все неправильно поняли (версия, поддерживаемая C ++ и Java, имеет мало общего с первоначальным значением ООП, как в SmallTalk), а затем притворилась святым Граалем. Конечно, есть некоторые аспекты, которые полезны, но зачастую это не лучший подход для разработки приложения.

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

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

Answer 5

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

Можно показать, что вероятность распространения изменений не может увеличиваться с расстоянием от изменения: если A зависит от B, а B зависит от C, и мы меняем C, то вероятность того, что A изменится не может быть больше, чем вероятность того, что B будет менять. Если B является прямой зависимостью от C и A является косвенной зависимость от C, то, в целом, чтобы минимизировать потенциальные затраты любого изменения в системе, мы должны минимизировать потенциальное число прямые зависимости.

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

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

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

Answer 6

Предлагаю вам прочитать статью Бьярне о Почему C ++ не просто объектно-ориентированный язык программирования

Answer 7

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

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

Answer 8

Раньше я был фанатом ООП ... Тогда реализация функций, обобщений и обратных вызовов часто могла сделать более элегантное и удобное решение в C ++, чем классы и виртуальные функции.

Другие известные имена тоже это поняли: http://harmful.cat -v.org / software / OO_programming /

Answer 9

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

Когда я разрабатываю в Objective-C, объекты являются естественным контейнером для данных и кода. Я все еще разрабатываю более или менее концепцию пакета с некоторыми новыми интересными функциями.

Answer 10

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

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

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

Только мои 0,02 доллара.