Есть ли у процедурного программирования какие-либо преимущества перед ООП?

Question

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

Однако мой опыт программиста на Java был иным. Я увидел массивную Java-программу, которую я спроектировал, переписал гуру Perl в 1/10 кода, который я написал, и, казалось бы, такой же надежный, как моя модель совершенства ООП. В моей архитектуре было много повторного использования, но более краткий процедурный подход позволил получить превосходное решение.

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

Кто-нибудь может привести примеры того, как эти сценарии будут выглядеть?

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

Answer 1

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

Хочешь джунглей?

Answer 2

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

Мы все привыкли к идее алгоритмов, которые говорят нам, как комбинировать различные процедуры и структуры данных для выполнения общих задач. Обратно посмотрите на «Шаблоны проектирования» от «Банды четырех», чтобы узнать, как комбинировать объекты для выполнения общих задач.

До того, как я узнал о шаблонах проектирования, я был в неведении относительно того, как эффективно использовать объекты, отличные от структуры супертипа.

Помните, что реализация интерфейсов так же важна, если не важнее, чем наследование. В свое время C ++ был ведущим примером объектно-ориентированного программирования, и использование интерфейсов скрыто по сравнению с наследованием (виртуальные функции и т. Д.). C ++ Legacy означало, что гораздо больше внимания было уделено повторному использованию поведения в различных руководствах и общих обзорах. С тех пор Java, C # и другие языки сделали интерфейс более привлекательным.

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

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

Answer 3

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

Answer 4

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

ЕСЛИ все работает и не собирается меняться, кого это волнует, если это ОО или нет? Работает. Это сделано. Если вам удастся быстрее достичь этой процедуры, тогда, возможно, это путь.

Но вы уверены, что это не изменится? Допустим, вы, вероятно, добавите новые типы структур данных. Каждый раз, когда вы добавляете новый тип структуры данных, с которым вы хотите, чтобы эти функции работали, вы должны убедиться, что вы нашли и изменили каждую из этих функций, чтобы добавить новый случай «else if» для проверки и добавить желаемое поведение влиять на новый тип структуры данных. Боль от этого увеличивается, когда программа становится больше и сложнее. Чем выше вероятность этого, тем лучше вам будет подход с ОО.

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

Answer 5

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

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

Answer 6

Полагаю, однажды Грэди Буч сказал, что вы действительно начинаете извлекать выгоду из ООП при 10000+ строках кода.

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

Answer 7

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

Answer 8

Если вы «думаете ОО» при программировании, то я не уверен, что имеет смысл спросить «когда мне вернуться к процедурному программированию?» Это равносильно тому, чтобы спрашивать Java-программистов, что они не могут делать, потому что Java требует классов. (То же языки .NET).

Если вам нужно приложить усилия, чтобы перестать мыслить процедурно, то я бы посоветовал спросить, как вы можете преодолеть это (если хотите); в противном случае оставайтесь с процессуальным. Если в ООП-режиме так много усилий, ваш ООП-код, вероятно, все равно не будет работать очень хорошо (пока вы не продвинетесь дальше по кривой обучения).

Answer 9

Мои два цента ...

Преимущества процедурного программирования

• Простое проектирование (быстрое подтверждение концепции, драматическое сражение с динамические требования)
• Простые межпроектные коммуникации
• Естественно, когда временной порядок имеет значение
• Меньше накладных расходов во время выполнения

Чем лучше процедурный код, тем ближе он к функциональному. И преимущества FP хорошо известны.

Answer 10

Вы можете написать плохое программное обеспечение в обеих концепциях. Тем не менее, сложное программное обеспечение гораздо проще писать, понимать и поддерживать на ОО-языках, чем на процедурном. Я написал очень сложные приложения ERP на процедурном языке (Oracle PL / SQL), а затем переключился на ООП (C #). Это был и остается глоток свежего воздуха.