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

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

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

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

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

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

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

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

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

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

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

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

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

Так что у меня будет (на 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);

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

Я думаю,

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Что ж, есть несколько альтернатив. Код, не являющийся ООП, в C ++ вместо этого может быть:

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

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

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

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

OOP is used a lot in GUI code, computer games, and simulations. Windows should be polymorphic - you can click on them, resize them, and so on. Computer game objects should be polymorphic - they probably have a location, a path to follow, they might have health, and they might have some AI behavior. Simulation objects also have behavior that is similar, but breaks down into classes.

For most things though, OOP is a bit of a waste of time. State usually just causes trouble, unless you have put it safely in the database where it belongs.

If we consider, for a moment, not object-orienatation itself but one of the keystones of object-orientation: encapsulation.

It can be shown that change-propagation probability cannot increase with distance from the change: if A depends on B and B depends on C, and we change C, then the probability that A will change cannot be larger than the proabability that B will change. If B is a direct dependency on C and A is an indirect dependency on C, then, more generally, to minimise the potential cost of any change in a system we must miminimise the potential number of direct dependencies.

The ISO defines encapsulation as the property that the information contained in an object is accessible only through interactions at the interfaces supported by the object.

We use encapsulation to minimise the number of potential dependencies with the highest change-propagation probability. Basically, encapsulation mitigates the ripple effect.

Thus one reason not to use encapsulation is when the system is so small or so unchanging that the cost of potential ripple effects is negligible. This is also, therefore, a case when OO might not be used without potentially costly consequences.

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

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

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

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

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

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

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

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

Конечно, если вам требуется использовать дизайн ООП, или инструментарий ООП,

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