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

Схожі: Як програмування робилося 20 років тому?

OOP є досить модною в наші дні, коріння в Simula 67 у 60-х роках, а пізніше зробило популярним Smalltalk та C ++ . У нас є DRY, SOLID, багато книг про моделі дизайну в об'єктно-орієнтованому світі.

Але які були основні принципи програмування до прийняття парадигми OOP? І які основні шаблони дизайну були?

Я був розробником Cobol до того, як навчився Java. Я розвивався понад 35 років.

Ще в часи процедурних мов більша частина обробки була виконана партією. Поверніться досить далеко в історію, і навіть компіляція програми була зроблена за допомогою колоди перфокартів у партії.

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

Відбулося раннє застосування принципу DRY. Створіть багато абзаців, щоб ви не повторювались. Структуровані методи кодування були розроблені в 1970-х роках, і Кобол додав структуровані слова (дієслова) до мови в 1985 році.

Як правило, коли ми писали нову програму Cobol, ми скопіювали стару програму Cobol і змінили назви для захисту невинних. Ми майже ніколи не кодували програму Cobol з чистого аркуша паперу чи порожнього екрану. Це велика модель дизайну, коли ви можете копіювати та вставляти цілі програми.

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

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

Це говорило, звичайно, були речі, які виконували в роботі практиків точно таку саму роль, як і дизайнерські зразки. Але ви будете розчаровані, почувши про них: типовим "фокусом гуру" в ті часи були речі, які зараз нам досить нудні - наприклад, окремо пов'язані списки, петлі, контрольовані індексом, посиленим на кожній ітерації, розумний "аксесуар "способи, які, здається, нічого не роблять, але надають можливість вільно змінити свою думку про деталі впровадження пізніше.

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

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

Важливими поняттями, запровадженими протягом цього часу, були приховування інформації, модульність та висока згуртованість / низька зв'язок. Дивіться твори Дейва Парнаса для деяких семінарських робіт на ці теми. Ознайомтесь також з роботами Ларрі Костянтина, Тома ДеМарко та Еда Юрдона.

Я вважаю, що одним з великих (крім самого структурованого програмування) була концепція передачі ручки навколо - в ОО є у вас об'єкт, і він містить стан і функціональність. Повернувшись до ОО, у вас з’явиться набір незалежних функцій, і ви передасте ручку в якийсь стан між ними - cookie, якщо хочете. Це дало вам принципи ОО, фактично не маючи ОО.

Ви можете бачити це багато в старому коді Win32, ви переходите в HANDLE, який був би непрозорим типом, який представляє деякий стан, виділений у ядрі Windows. Ви могли це зробити самостійно, передавши вказівник на структуру, яку раніше було виділено як перший параметр функціям, що оперували цими даними.

Оскільки очевидного ще ніхто не згадував: однією великою схемою дизайну в процедурну епоху був «Об’єкт». Як і багато популярних моделей дизайну раніше (наприклад, підпрограма) та після (наприклад, Iterator), вона стала настільки популярною, що навіть отримала мовну підтримку.

"Машина з кінцевим станом" може вважатися зразком, і ФДМ були написані (наприклад, для протоколів зв'язку), використовуючи мови попереднього виводу.

Також "обробники переривань" та TSR використовували популярність, наприклад, у DOS.

Такі терміни, як "Код спагетті" та "Єдиний пункт виходу", насправді є наслідком цієї епохи. Сьогодні ми називаємо код, який нам не подобається "код спагетті", але насправді це посилання на код, пов'язаний (погано) з GOTOs та JMP.

(Сьогодні ми страждаємо від "коду равіолі", в якому код є як купа незв'язаних, щільно упакованих класів, як тарілка з равіолі. Однак деякі експерти OO виправдано запитують: "Але це не те, що повинен вважати ОО виглядає як?")

Сьогодні "Єдиний пункт виходу" - це лише розчаровуючи дорожній рух. Дуже багато чортів, з якими я розмовляю, навіть не чули про це, і викликають жах, коли я це пояснюю. Але за старих часів це означало, що не вискочуйте з кодового блоку раптово і не перетворюйтесь на код спагетті. Перейти вперед до кінця логіки, а потім витончено вийти.

Розтягуючи мою пам’ять, повертаючись назад, я, мабуть, пам’ятаю, що ідея поєднання коду в процедури був великим стрибком вперед. Ідея, що ви можете упакувати процедури в сумісні модулі для багаторазового використання, була свого роду Святим Граалом програмування.

EDIT: "Код, що самозмінюється" також був зразком, який застосовувався особливо в оригіналі Doom. Ось де програма насправді перезаписає свої вказівки більш швидкими інструкціями на основі свого стану. Коли я був тикером, який проходив курс програмування в Музеї науки, мій викладач суворо попередив нас: "Не пишіть самомодифікуючий код!"

EDIT EDIT: Однак перед Інтернетом слово проходило набагато повільніше. Ідея впровадження алгоритмів та структур даних раніше була значно більшою угодою. Сьогодні я весь час сортую, навіть не знаючи, який сорт я використовую. Але тоді вам довелося це кодувати самостійно. Я пам’ятаю одну статтю, яка розповідала про проблеми програмування, які займали дні, які сьогодні ми закінчуємо за півгодини чи менше. Настільки чітке програмування «алгоритмічного» та «структури даних», можливо, було б у списку, набагато більше, ніж сьогодні.