Каковы были шаблоны проектирования эпохи процедурного программирования? [закрыто]

Похоже: как программирование было сделано 20 лет назад?

В настоящее время ООП довольно модно, его корни уходят в Simula 67 в 1960-х годах, а позже стали популярными благодаря Smalltalk и C ++ . У нас есть DRY, SOLID, много книг о шаблонах проектирования в объектно-ориентированном мире.

Но каковы были основные принципы программирования до широкого внедрения парадигмы ООП? И каковы были основные шаблоны дизайна?

Я был разработчиком Cobol, прежде чем я изучил Java. Я разработал более 35 лет.

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

В отличие от Kilian Фот по утверждению , мы имели дизайн модели еще в 1970 - х и 1980 -х годов. Был определенный способ кодирования многофайлового совпадения / слияния в Cobol. Существовал определенный способ кодирования добавления транзакций в основной (ленточный) файл в Cobol. Был определенный способ генерации отчетов в Cobol. Вот почему Report Writer от IBM никогда не завоевывал популярность во многих магазинах Cobol.

Было раннее применение принципа СУХОЙ. Создайте много абзацев, чтобы не повторяться. Методы структурированного кодирования были разработаны в 1970-х годах, а Кобол добавил в язык структурированные слова (глаголы) в 1985 году.

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

Было так много шаблонов проектирования Cobol, что программисту Cobol потребовались годы, чтобы выучить их все. Это одна из причин того, что программисты Cobol сегодня по большей части все еще используют синтаксис 1985 года.

«Шаблонов проектирования» в программном обеспечении не существовало в ту эпоху, о которой вы говорите, потому что концепция не была изобретена. Это я не будучи легкомысленным - это на самом деле является причиной; называние узнаваемым именем - это то, что делает шаблон проектирования «шаблоном дизайна», а не просто кодом, который вы продолжаете использовать в той или иной форме (например, «фабрика», а не «тип статического класса, который мне нравится использовать, а не ассортимент конструкторов ") и сама концепция не является исключением.

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

Правильно, вещи, которые мы сейчас воспринимаем как должное - иногда даже являющиеся частью языков, которые мы используем - раньше были продвинутыми (а иногда и ревностно охраняемыми) концепциями, известными только более опытным программистам. Скорее всего, почти все не совсем тривиально, что вы изучаете сегодня на базовом курсе программирования, прошло этап, когда он был моральным эквивалентом «модели проектирования» для практиков того времени. Построение программного обеспечения, возможно, еще не является строгой инженерной дисциплиной, но если вы изучите современное состояние 50-х и 60-х годов, вы не сможете отрицать, что оно прошло огромный путь с самого начала.

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

Важными концепциями, представленными в это время, были сокрытие информации, модульность и высокая когезия / низкая связь. Посмотрите работы Дэйва Парнаса для некоторых оригинальных работ по этим темам. Также ознакомьтесь с работами Ларри Константина, Тома Демарко и Эда Юдона.

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

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

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

«Конечный автомат» может считаться шаблоном, и FSM были написаны (например, для протоколов связи) с использованием языков, предшествующих OO.

Также «обработчики прерываний» и TSR были популярны, например, в DOS.

Такие термины, как «Код спагетти» и «Единая точка выхода» на самом деле являются возвратами к той эпохе. В настоящее время мы называем код, который нам не нравится, «код спагетти», но на самом деле это ссылка на код, связанный (плохо) с GOTO и JMP.

(Сегодня мы страдаем от «кода равиоли», в котором код похож на кучу несвязанных, тесно упакованных классов, очень похоже на тарелку равиоли. Однако некоторые эксперты по ОО справедливо спрашивают: «Но разве это не то, что ОО должен выглядит как?")

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

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

РЕДАКТИРОВАТЬ: «Самомодифицирующийся код» был также шаблон, используемый в оригинальной Doom. Вот где программа фактически перезаписывает свои инструкции более быстрыми инструкциями, основанными на ее состоянии. Когда я учился на курсе по программированию в Музее науки, мой инструктор строго предупредил нас: «Не пишите самоизменяющийся код!»

РЕДАКТИРОВАТЬ РЕДАКТИРОВАТЬ: Тем не менее, до Интернета, слово путешествовало гораздо медленнее. Идея реализации Алгоритмов и Структур Данных была намного более крупной. Сегодня я все время сортирую, даже не зная, какой сорт использую. Но тогда вы должны были сами это кодировать. Я помню одну статью, в которой говорилось о проблемах программирования, которые раньше занимали дни, которые мы сегодня выбиваем за полчаса или меньше. Таким образом, действительно осмысленное «алгоритмическое» и «структурирование данных» должно быть в списке, гораздо больше, чем сегодня.