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

24

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

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

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

Vorac
источник
11
ООП на самом деле немного старше: см. En.wikipedia.org/wiki/Smalltalk . Кроме того, DRY не уникален для ООП; принцип может быть (и должен быть) во всех парадигмах программирования, хотя у них разные ответы относительно того, как этого достичь.
tdammers
4
ООП в основном происходит из Симулы
Чарльз Сальвия
8
ООП, имеющий свои корни в C ++ ??? Дети в эти дни ... :(
Андрес Ф.
5
К счастью, все эти бесполезные маркетинговые трюки, все эти шумихи - это относительно новая вещь в нашей отрасли. В старые времена мы просто программировали, без всякой хрени.
SK-logic
@AndresF., Не стесняйтесь редактировать это прямо в моем вопросе.
Ворак

Ответы:

31

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

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

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

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

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

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

Гилберт Ле Блан
источник
2
+1. У меня был такой же опыт работы с Cobol, Pascal и обучением основам на Vic-20. Было много вещей, которые я использовал повторно и скопировал вокруг.
JohnP
Как насчет BONSOP, который все еще используется сегодня;)
dbasnett
Неправильно называть «копировать / вставлять / изменять» «шаблон дизайна» (по крайней мере, так как мы используем этот термин сегодня) - возможно, это скорее «шаблон кодирования»?
Изката
@Izkata: На самом деле это не шаблон кодирования, так как вы избегаете большей части кодирования. Как насчет «шаблона»? Вы правы, что копирование / вставка / изменение не является хорошим дизайном по современным стандартам. Тогда это было лучшее, что у нас было.
Гилберт Ле Блан
1
Шаблон дизайна такой же, как и в C & P Cobol, синглтон всегда кодируется одинаково - вы даже можете получить некоторые IDE, чтобы выложить для вас образец. Это ничем существенно не отличается от вырезать и вставить.
gbjbaanb
25

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

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

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

Килиан Фот
источник
4
шаблон проектирования - это просто имя, которое Бек и Каннингем придумали, чтобы формализовать концепцию шаблона кода, который повторяется. Они сделали это в 1987 году. Фаулер опубликовал свою книгу в 2002 году и сделал их популярными.
gbjbaanb
1
@gbjbaanb, я думал, что шаблоны проектирования берут свое начало, по крайней мере, несколько десятилетий назад
Vorac
3
@Vorac это не для программного обеспечения
комнат
18

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

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

TMN
источник
Да, это то, что я узнал 25 лет назад
Binary Worrier
10

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

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

gbjbaanb
источник
Это довольно интересно. Я ищу и другие примеры. Например, как можно «построить логику вокруг структур данных, а не наоборот»?
Vorac
2
То же, что вы делаете сейчас, за исключением того, что ваши методы являются бесплатными функциями, связанными с вашими структурами данных соглашением, импликацией или документацией, а не специальной языковой поддержкой.
бесполезно
1
Это похоже на то, как JavaScript делает OO, только с JS указатели на функции могут быть частью структуры, которую вы передаете. На самом деле ничего не меняется, мы просто
покрываем
5

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

Йорг Миттаг
источник
3

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

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

ChrisW
источник
3

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

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

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

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

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

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

обкрадывать
источник