Можно ли успешно спроектировать и построить процедурное (императивное) приложение?

Question

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

Answer 1

Примеры успешных процедурных заявлений ??

Вы имеете в виду, например, ядро ​​Linux? Ядро BSD? Веб-сервер Apache? Подавляющее большинство пользовательских утилит Unix? Такие приложения, как это?

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

Рассмотрим весь код Java, C # или VB, который, хотя и написан на языке программирования с поддержкой ООП, единственная причина, по которой они вообще используют ООП, - взаимодействие с внешними библиотеками или системами. Между тем, сами приложения, хотя и используют платформы ООП, скорее всего, являются довольно процедурными при разработке и реализации.

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

Answer 2

Хотя я не могу указать на какую-либо существующую систему напрямую, существует огромное количество устаревших корпоративных систем, написанных до OO COBOL. Многие классические программы 4GL являются процедурными и нацелены на разработку систем с высокой степенью целостности. Некоторые хорошо написаны, другие не так много.

Книги включают в себя «COBOL от Micro до мэйнфреймов», «Руководство по программированию Enterprise COBOL».

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

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

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

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