Стоимость разработки процедурного программирования по сравнению с ООП?

Покопавшись в Google, я нашел этот документ здесь . Я использовал поисковые запросы, ориентированные на объект "Производительность".

В первых абзацах говорится

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

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

Большинство из этих вопросов связано с тем, что производительность отдельных программистов варьируется на порядок или более; если у вас есть объектно-ориентированный программист, который является одним из группы с производительностью x, и «процедурный» программист, который является программистом в 10 раз, процедурный программист может выиграть, даже если объектно-ориентированный программист в некотором смысле быстрее.

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

Вы можете прочитать статью Фреда Брукса «Нет серебряной пули».

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

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

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

Так что, я думаю, стоимость OO в долгосрочной перспективе будет ниже по сравнению с процедурой.

Я думаю, С.Лотт имел в виду феномен «неповторимого эксперимента», то есть вы не можете написать приложение X процедурно, а затем перемотать время назад и написать его OO, чтобы увидеть, в чем разница.

вы можете написать одно и то же приложение дважды двумя разными способами, но

• вы бы узнали что-то о приложении, которое делает это первым, что поможет вам вторым способом, и
• вы можете быть лучше в OO, чем в процедурном, или наоборот, в зависимости от вашего опыта, характера приложения и выбранных инструментов

поэтому на самом деле нет прямой основы для сравнения

эмпирические исследования также бесполезны по схожим причинам - разные приложения, разные команды и т. д.

Смена парадигмы сложна, и небольшой процент программистов, возможно, никогда не осуществит переход

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

если нет, что ж, пора бы доработать резюме ... ;-)

Хорошая идея. Прямое сравнение. Напишите приложение X в процедурном стиле и в стиле OO и измерьте что-нибудь. Стоимость разработки. Прибыль на инвестиции.

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

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

Сказав это, вы должны сосредоточиться на том, что на самом деле видят другие.

1. Пора построить что-то, что работает.

2. Рейтинг ошибок и проблем.

Если ваш подход лучше, вы добьетесь успеха, и люди захотят узнать, почему.

Когда вы объясняете, что объектно-ориентированный подход ведет к вашему успеху ... ну ... вы выиграли спор.

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

Моя компания в середине 90-х годов разработала ориентированный на события процедурно-ориентированный дизайн программного обеспечения CAM, созданного с использованием VB3. Адаптация программного обеспечения к новым машинам занимала много времени. Долгое время, чтобы проверить влияние исправлений ошибок и новых функций.

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

Ключ в том, чтобы объяснить, ПОЧЕМУ ООП принесет пользу проекту. Используйте такие вещи, как рефакторинг Фаулера и шаблоны проектирования, чтобы показать, как новый дизайн сокращает время на выполнение каких-либо задач. Также укажите, как вы добираетесь от точки А до точки Б. Рефакторинг поможет показать, как можно иметь рабочие промежуточные этапы, которые можно отправить.

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

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

Так что в небольшом проекте процедурный дизайн МОЖЕТ быть дешевле, потому что он быстрее и у вас нет недостатков. Но в большом проекте вы очень быстро освоитесь, используя только простую парадигму, такую ​​как процедурное программирование.

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

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

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

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

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

Итак, вам нужно сосредоточиться на 1). Препятствует ли поддержание текущих процессов будущему развитию? 2) Как разные методы повлияют на №1?