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

Ответ 1

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

Если не использовать ООП:

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

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

• Ваш код уже не OOP: Не стоит переносить свой код, если ваш старый код не является ООП. В 1995 году есть цитата из Richard Stallman в 1995 году.

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

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

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

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

Ответ 2

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

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

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

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

Ответ 3

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

Ответ 4

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

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

Ответ 5

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

Ответ 6

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

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

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

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

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

Ответ 7

Ну, есть несколько альтернатив. Вместо кода OOP на С++ может быть:

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

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

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

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

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

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

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

Ответ 8

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

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

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

Только мои $0,02.

Ответ 9

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

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

Ответ 10

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

Другие большие имена тоже поняли: http://harmful.cat-v.org/software/OO_programming/

Ответ 11

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

tl; dr зависит от проблемы.

Ответ 12

Я бы сказал, что наибольшее преимущество С++ OOP - наследование и polymorphism (виртуальная функция и т.д.). Это позволяет повторно использовать и расширяемость кода

Ответ 13

С++, используйте OOP - - - C, нет, с некоторыми исключениями

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

В C это более сложный вызов. Хотя вы, безусловно, можете написать произвольно объектно-ориентированный код в C, достаточно боли, с которой вы сразу же сталкиваетесь с языком, чтобы использовать его. Возможно, вы можете более эффективно отказаться от шаблона проектирования и нестандартного проектирования и программирования, поскольку C предназначался для использования.

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

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

Но если бы вы знали, что программа станет такой сложной, вы не должны писать ее на C в первую очередь...

Ответ 14

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

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

Итак, я бы (в C)

MyEvent *ev1 = new_eventhandler();

set_event_callback_func(ev1, callback_one);
ev1->setfd(fd1);

MyEvent *ev2 = new_eventhandler();

set_event_callback_func(ev2, callback_two);
ev2->setfd(fd2);

destroy_eventhandler(ev1);
destroy_eventhandler(ev2);

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

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

В противном случае я предпочитаю более процедурный/функциональный подход.

Ответ 15

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

Конечно, я все еще использую другие объекты в своем коде (std::vector et al), и я использую пространства имен, чтобы помочь организовать мои функции, но зачем ставить код в объекты, пока это не будет полезно? В равной степени не уклоняйтесь от бесплатных функций в решении OO.

Ответ 16

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

Когда С++ впервые поймал, появились циллионы классов строк. Все, что вы могли себе представить, чтобы сделать строку (восходящий, вниз, обрезка, токенизация, синтаксический анализ и т.д.), Было членом функции некоторого строкового класса.

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

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

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

Ответ 17

ИМХО, у меня есть ощущение, что концепция ООП не совсем соответствует потребностям Больших Данных, так как ООП предполагает все вещи, которые должны храниться в памяти (концепция Объектов и переменных-членов). Это всегда приводит к требованию к памяти и тяжелым приложениям, когда ООП используется, например, для обработки больших изображений. Вместо этого простота C может использоваться с интенсивным параллельным вводом-выводом, делая приложения более эффективными и простыми в реализации. Это 2019 год Я пишу это сообщение... Все может измениться через год! :)