手続き型プログラミング時代のデザインパターンは何でしたか？[閉まっている]

同様：20年前にプログラミングはどのように行われましたか？

OOPは最近非常にファッショナブルで、1960年代にSimula 67にルーツを持ち、後にSmalltalkとC ++で人気を博しました。DRY、SOLID、オブジェクト指向の世界のデザインパターンに関する多くの本があります。

しかし、OOPパラダイムが広く採用される前のプログラミングの主な原則は何でしたか？そして、主要な設計パターンは何でしたか？

Javaを学ぶ前は、Cobol開発者でした。私は35年以上にわたって開発してきました。

手続き型言語の時代には、ほとんどの処理はバッチで行われていました。歴史をさかのぼると、プログラムのコンパイルでさえ、パンチカードのデッキでバッチ処理されていました。

Kilian Fothの主張とは反対に、1970年代と1980年代にはデザインパターンがありました。Cobolで複数ファイルの一致/マージをコーディングする特定の方法がありました。Cobolのマスター（テープ）ファイルにトランザクションを追加する特定の方法がありました。Cobolでレポート生成をコーディングする特定の方法がありました。IBMのReport Writerが多くのCobolショップで実際に注目を集めることがなかったのはそのためです。

DRY原則の早期適用がありました。繰り返しのないように、たくさんの段落を作成してください。構造化コーディング技術は1970年代に開発され、Cobolは1985年に言語に構造化された単語（動詞）を追加しました。

一般に、新しいCobolプログラムを作成したときに、古いCobolプログラムをコピーし、無実の人を保護するために名前を変更しました。空白の用紙または空白の画面からCobolプログラムをコーディングしたことはほとんどありませんでした。プログラム全体をコピーして貼り付けることができる場合、これは大きなデザインパターンです。

Cobolの設計パターンは非常に多く、Cobolプログラマーがそれらをすべて習得するのに何年もかかりました。それが、今日のCobolプログラマーのほとんどが1985年の構文を使用している理由の1つです。

ソフトウェアの「デザインパターン」は、コンセプトが発明されていないため、あなたが話す時代には存在しませんでした。これは私が軽んじられているのではなく、実際にその理由です。認識可能な名前と呼ばれることは、デザインパターンを何らかの形で使用し続ける単なるコードではなく「デザインパターン」にするものです（例えば、「私が使用するのではなく、コンストラクタの品揃え」）、コンセプト自体も例外ではありません。

そうは言っても、もちろん、現在の設計パターンと同じように、実務家の仕事においてまったく同じ役割を果たしたものがありました。しかし、あなたはそれらについて聞いてがっかりするでしょう：当時の典型的な「教祖のトリック」は今私たちにとって非常に退屈なものでした。 "実装の詳細について後から気が変わるまでの余裕を与えるだけのように見えるメソッド。

そうです、今では当たり前のことですが、使用する言語の一部である場合もありますが、以前は経験豊富なコーダーのみが知っていた高度な（時には熱心に保護された）概念でした。おそらく、今日の基本的なプログラミングコースで学ぶことは、決して些細なことではないもののほとんどが、時代の実践者にとって「デザインパターン」に相当する道徳的な段階を経たものです。ソフトウェアの構築はまだ厳密なエンジニアリングの分野ではないかもしれませんが、50年代および60年代の最先端技術を研究すれば、それが最初から巨大な方法になったことを否定することはできません。

以前の大きなパラダイムは、構造化プログラミングでした。UMLの代わりに、さまざまな異なる図（フローチャート、データフロー図、構造図など）がありました。開発は主にトップダウンであり、機能分解のプロセスに従いました。基本的なアイデアの1つは、プログラム構造を菱形に似たものにすることでした。最上位のメインモジュールは、下位レベルモジュールのルーチンを呼び出す上位レベルの制御モジュールに拡張されます。これらの低レベルモジュールは、さらに低レベルのモジュール上に構築されており、それらはすべて（理論的には）少数の基本的なI / Oルーチンに収束しました。高レベルのモジュールにはプログラムロジックが含まれているはずでしたが、低レベルのモジュールはデータの整合性とエラー処理に関心がありました。

この間に導入された重要な概念は、情報の隠蔽、モジュール性、および高い凝集度/低い結合度でした。これらのトピックに関するいくつかの独創的な論文については、Dave Parnasの作品を参照してください。また、Larry Constantine、Tom DeMarco、Ed Yourdonの作品もご覧ください。

構造化されたプログラミング自体以外の大きなものの1つは、ハンドルを渡す概念です-オブジェクト指向にはオブジェクトがあり、状態と機能が含まれています。OOの前に戻ると、独立した関数が多数あり、それらの間の状態にハンドルを渡します（必要に応じてCookie）。これにより、実際にオブジェクト指向を持たずにオブジェクト指向の原則が得られました。

これは古いWin32コードでよく見ることができます。Windowsカーネルに割り当てられた状態を表す不透明な型であるHANDLEを渡します。そのデータを操作する関数の最初のパラメーターとして以前に割り当てた構造体へのポインターを渡すことで、自分でそれを行うことができます。

明らかなものについてはまだ誰も言及していないので、手続き型時代の大きなデザインパターンの1つはObjectでした。多くの一般的なデザインパターンの前（例：サブルーチン）および後（例：イテレーター）のように、非常に人気があり、言語サポートさえも受けました。

「有限状態マシン」はパターンとしてカウントされる場合があり、FSMはOO以前の言語を使用して（たとえば、通信プロトコル用に）作成されました。

また、「割り込みハンドラ」とTSRは、DOSなどでよく使用されていました。

「スパゲッティコード」や「出口のシングルポイント」などの用語は、実際にはその時代への先祖返りです。今日、私たちは「スパゲッティコード」が好きではないコードを呼び出しますが、実際には、GOTOやJMPと結び付けられた（ひどく）コードへの参照です。

（今日、私たちは「ラビオリのコード」に苦しんでいます。このコードは、ラビオリのプレートによく似た、関連のない緊密にパッケージ化されたクラスの束のようなものです。のように見える？"）

今日の「出口の単一ポイント」は、イライラするリファクタリングのロードバンプです。私が話す多くの開発者はそれを聞いたことがなく、私がそれを説明するのに驚いています。しかし、昔は、突然コードブロックから飛び出してスパゲッティコードに飛び込まないでください。ロジックの最後にジャンプしてから、正常に終了します。

記憶を引き伸ばして、さかのぼって、コードをプロシージャにまとめるというアイデアは大きな前進だったことを覚えているようです。プロシージャを相互運用可能で再利用可能なモジュールにパッケージ化できるという考えは、プログラミングの聖杯のようなものでした。

編集：「自己修正コード」は、元のDoomで特に使用されるパターンでもありました。これは、プログラムがその状態に基づいて、より高速な命令で実際に命令を上書きする場所です。私が科学博物館でプログラミングコースを受講したとき、私のインストラクターは「自己修正コードを書かないでください！」と厳しく警告しました。

編集編集：ただし、インターネットが登場する前は、単語の移動はもっとゆっくりでした。アルゴリズムとデータ構造を実装するという考えは、以前よりもはるかに大きなものでした。今日、私は自分がどんなソートを使用しているかさえ知らずに、常にソートしています。しかし、当時は自分でコーディングする必要がありました。プログラミングの課題について話していた1つの記事を覚えています。これは、今日では30分以内にノックアウトするのに数日かかっていました。そのため、本当に意識的な「アルゴリズム」および「データ構造」プログラミングが、おそらく今日よりもリストに載ることでしょう。