Затраты на разработку процедурного программирования по сравнению с ООП?
Вот более сложный подход, который группирует элементы по их количеству; заметьте, однако, что это предполагает, что имя элемента не будет содержать никаких цифр, кроме номера группы в конце.
XSLT 1.0
<xsl:stylesheet version="1.0"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:output method="xml" version="1.0" encoding="UTF-8" indent="yes"/>
<xsl:strip-space elements="*"/>
<xsl:key name="field-by-group" match="*" use="translate(name(), translate(name(), '0123456789', ''), '')" />
<xsl:template match="/results">
<xsl:copy>
<xsl:copy-of select="status | info"/>
<products>
<xsl:for-each select="*[starts-with(name(), 'prod')]">
<product>
<xsl:for-each select="key('field-by-group', substring-after(name(), 'prod'))">
<xsl:element name="{translate(name(), '0123456789', '')}">
<xsl:value-of select="."/>
</xsl:element>
</xsl:for-each>
</product>
</xsl:for-each>
</products>
</xsl:copy>
</xsl:template>
</xsl:stylesheet>
9 ответов
После ввода по абсолютному адресу вокруг с google I нашел данную статью здесь. Критериями поиска, которые я использовал, является объектно-ориентированная Производительность.
Вводные абзацы продолжают
Введение объектно-ориентированной технологии, кажется, не препятствует полной производительности на новых больших коммерческих проектах, но это ни один, кажется, не улучшает его в первых двух поколениях продукта. На практике управляющее влияние может быть бизнес-рабочим процессом а не методологией.
Я думаю, что Вы найдете, что Объектно-ориентированное программирование лучше при определенных обстоятельствах, но нейтрально для всего остального. То, что продало моих боссов при преобразовании приложения CAD/CAM моей компании к объектно-ориентированной платформе, - то, что я точно показал точные области, в которых это поможет. Фокус не был на методологии в целом, но как это поможет нам, продал некоторую определенную проблему, которую мы имели. Поскольку нас имел расширяемую платформу для добавления большего количества форм, отчетов, и контроллеров машины и использования наборов для удаления ограничения памяти более старого дизайна.
Большинство все эти вопросы соединены проблемой, что отдельная производительность программиста варьируется порядком величины или больше; если у Вас, оказывается, есть программист OO, который является одним из gruop в производительности x и "процедурным" программистом, который является 10x, программист, процедурный программист склонен победить, даже если OO быстрее в некотором смысле.
Существует также проблема, что кодирование производительности обычно - только 10-20 процентов общего усилия в реалистическом проекте, поэтому более высокая производительность не оказывает большое влияние; даже то гипотетическое 10x программист или бесконечно быстрый программист, не может сократить полное усилие больше этого 10-20 процентов.
Вы не могли бы взглянуть на статью Fred Brooks "Никакая Серебряная пуля".
OO или процедурное предложение другому способу разработать и оба могут быть дорогостоящими, если плохо управляемый.
Если мы предполагаем, что работы сделаны лучшим человеком в обоих случаях, я думаю, что результат мог бы быть равным с точки зрения стоимости.
Я полагаю, что разница в стоимости будет идти, как Вы будете этапом технического обслуживания, где необходимо будет добавить опции и изменить текущие функции. Процедурный проект более тверд иметь автоматическое тестирование, является меньше подвергающимся, чтобы смочь расшириться, не влияя на другую часть, и больше тяжелее для понимания части понятия под частью (потому что связная часть не группируется необходимая).
Так, я думаю, стоимость OO будет ниже в конечном счете по сравнению с Процедурным.
Хорошая идея. Сравнение лицом к лицу. Запишите приложение X в процедурном стиле, и в стиле OO и измерьте что-то. Стоимость для разработки. Доход от инвестиций.
Что означает записать то же приложение в двух стилях? Это было бы другое приложение, не так ли? Процедурные люди мешали бы этому, люди OO обманывали, когда они использовали наследование или обмен сообщениями или инкапсуляцию.
Не может быть такого сравнения. Нет никакого основания для сравнения двух "версий" приложения. Это похоже на выяснение, если яблоки или апельсины более экономически эффективны будучи фруктами.
Однако необходимо сфокусироваться на вещах, которые могут на самом деле видеть другие люди.
Время для создания чего-то, что работает.
Уровень ошибок и проблем.
Если Ваш подход будет лучше, то Вы будете успешны, и люди захотят знать почему.
Когда Вы объясняете, что OO приводит к Вашему успеху..., хорошо... Вы выиграли спор.
я думаю, что S.Lott отсылал к "неповторяемому эксперименту" явление, т.е. Вы не можете записать, что приложение X процедурно затем перематывает время и пишет этому OO для наблюдения, каково различие.
Вы могли записать тому же приложению дважды два различных пути, но
- Вы узнали бы что-то о приложении, делающем его первый путь, который поможет Вам вторым способом, и
- можно быть лучше в OO, чем в процедурном, или наоборот, в зависимости от опыта и природы приложения и выбранных инструментов
таким образом, действительно нет никакого прямого основания для сравнения
эмпирические исследования аналогично бесполезны, по подобным причинам - различные приложения, различные команды, и т.д.
сдвиги парадигмы являются трудными, и небольшой процент программистов никогда не может делать переход
если Вы свободны разработать свой путь, то решение просто: разработайте вещи Ваш путь, и когда Ваши коллеги замечают, что Вы кодируете круги вокруг них, и Ваш код не повреждается почти как часто и т.д., и они спрашивают Вас, как Вы делаете это, затем преподаете им ООП (наряду с TDD и любыми другими хорошими методами, которые можно использовать),
в противном случае хорошо могло бы быть пора полировать резюме... ;-)
В этой статье ничто не говорится об ООП по сравнению с Процедурным. Но я думал бы, что Вы могли использовать подобные метрики от своей компании для обсуждения.
Я нахожу это интересным, поскольку моя компания начинает исследовать инициативу ROWE. На нашей первой сессии было очевидно, что мы в настоящее время не получаем достаточно метрик на результатах.
Таким образом, необходимо сфокусироваться на 1) Обслуживании текущих процессов препятствует будущей разработке? 2) Как различные методы собираются влиять на № 1?
Ключ время. Сколько времени занимает компания для изменения дизайна, чтобы добавить новые опции или зафиксировать существующие. Любое исследование, которое Вы делаете, должно сфокусироваться на той области.
Моя компания имела управляемый событиями процедурно-ориентированный дизайн для программного обеспечения CAM в середине 90-х, созданной с помощью VB3. Требовалось много времени для адаптации программного обеспечения к новым машинам. Долгое время для тестирования эффектов исправлений ошибок и новых возможностей.
С VB6 пришел, я смог чертить график текущий дизайн и новый дизайн, который решил проблему тестирования и адаптации. Нетехнический босс схватил то, что я пытался делать сразу же.
Ключ должен объяснить, ПОЧЕМУ ООП принесет пользу проекту. Используйте вещи как Refactoring Fowler и Шаблонами разработки, чтобы показать, как новый дизайн понизит время, чтобы сделать вещи. Также включайте, как Вы добираетесь от Point Point B. Refactoring, поможет с показом, как у Вас могут быть рабочие промежуточные стадии, которые могут быть поставлены.
Я сомневаюсь, что Вы найдете категорическое исследование. Поскольку несколько человек упомянули, что это не восстанавливаемый эксперимент. Вы найдете неподтвержденную информацию, многое из нее. Некоторые люди могут найти некоторые статистические исследования, но я исследовал бы их тщательно. Я не знаю ни о каких действительно хороших.
Я также выскажу другое мнение, нет такой вещи как чисто объектно-ориентированная или чисто процедурная в реальном мире. Многие, если не большинство методов объекта записано с процессуальным кодексом. В то же время много процедурных программ используют методологии OO, такие как инкапсуляция (также называют абстракцию некоторыми).
Не понимайте меня превратно, OO и процедурные программы смотрят и отличаются, но это - вопрос темно-серого цвета по сравнению со светло-серым вместо черного цвета и белого цвета.
Я не думаю, что Вы найдете исследование как этот. По крайней мере, необходимо определить то, что Вы подразумеваете под "стоимостью". Поскольку разработка ООП так или иначе медленнее, таким образом, на краткосрочной разработке, возможно, быстрее с процедурным программированием. На очень коротком сроке, возможно, кодирование спагетти еще больше быстрее.
Но когда проект начинает расти, вещи противоположны, потому что разработка ООП лучше всего показана для управления сложностью кода.
Таким образом в маленьком проекте, возможно, процедурный дизайн МОЖЕТ быть более дешевым, потому что это быстрее, и у Вас нет недостатков. Но в большом проекте Вы получите палку очень быстро использование только простой парадигмы как процедурное программирование