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

Question

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

Answer 1

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

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

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

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

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

Answer 2

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

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

Answer 3

В 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);

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

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

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

Answer 4

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

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

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

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

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

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

Answer 5

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

Answer 6

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

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