手続き型言語におけるデザインパターン

Question

オブジェクト指向型言語におけるデザインパターンはGoFが定義して存在していますが，手続き型言語においては同様のデザインパターンというものは存在しているのでしょうか？
デザインパターンを勉強していて単純に疑問に思いました．よろしくお願いします．

Answer 1

Wikipedia[en]: Software design patternによると、デザインパターンはもともと建築学で考えられた言葉だったようです。それがプログラミングの世界にも取り入れられ、GoFによる書籍「オブジェクト指向における再利用のためのデザインパターン」によって一躍有名になりました。この書籍は題名通りオブジェクト指向言語(サンプルはC++とSmalltalk)でオブジェクト指向で設計するときのデザインパターンを記載しています。そのため、単に「デザインパターン」と言った場合「オブジェクト指向デザインパターン(object-oriented design patterns)」を示すことが多いと思われます。

では、オブジェクト指向に限定した物しかデザインパターンと言わないのかというとそうではないようです。たとえばMVC(Model-View-Controller)はオブジェクト指向に限らない設計ですが、「建築デザインパターン(architectural design pattern)※1」といわれるデザインパターンの一種とされます。このようにオブジェクト指向以外での設計に関する部分でデザインパターンという言葉が使われる場合があると言うことは注意すべき事かと思います。

※1 architectural design patternの適当な訳語がわかりませんでした。なお、建築学とは無関係です。

お気づきかと思いますが、オブジェクト指向デザインパターンと建築デザインパターンでは見ているレベルが異なります。建築デザインパターンはもっと大きなプログラム全体の設計をみており、オブジェクト指向デザインパターンはそこから落とし込んでいったクラスの構成などの設計をみています。また、もともとオブジェクト指向デザインパターンは命令型オブジェクト指向のために考えられたと言うこともあり、非オブジェクト指向や関数型ではそのまま適用することが難しい場合があります。では、非オブジェクト指向や関数型のために考えられたデザインパターンはあるのでしょうか？

まず、関数型について検索した限り、GoFの書籍のようにまとまった何かというのはどうやら無いようです。しかし、GoFの書籍にあるようなパターンについて、その目的を達するために関数型であればどのように設計すべきかということが書かれたサイトはいくつか見受けられました。ですので、関数型デザインパターンというものが全くないというわけではないけど、まだ、それほどまとまっていないと思われます。

次に、Cのようなオブジェクト指向以前の場合はどうでしょうか？デザインパターンという言葉が有名になるGoFの書籍以前でも、プログラミングにおける設計の研究は行っていたと思われますが、デザインパターンとは呼ばれなかったのでは無いかと思います。たとえば、ある関数を呼び出すとポインタを返すが、エラーがあった場合はNULLを返し、errnoをセットするという関数の設計方針があります。Cのmallocやfopenがそのような設計です。しかし、このような設計方針に名前を付けて、まとめた物があるかというと私は知りません。そもそもこの設計方針がベストなのかというのも疑問が残るところです。また、Cではそのような設計にせざるを得ないだけであり、Goではまた別のエラーの時の返し方ができます。言語依存が強すぎて言語をまたいだデザインパターンのような物にできなかったのかも知れません※2。

※2 オブジェクト指向デザインパターンであっても、全てのオブジェクト指向言語にそのまま適用できるとは限りません。言語によってはより最適な方法が存在する場合があります。例えば、イテレーターパターンをRubyでそのまま使うことは良い方法とは全く言えません。

ということで、オブジェクト指向デザインパターンと同レベルのまとまった物というのが有るかというこというと、それは無いと思います。しかし、デザインパターンという考え方自体が無いかというと、そこは有ると思います。また、MVCのような言語の枠をさらに越えたところでは、ある意味デザインパターンは全ての言語について存在し得るとも言えます。

Answer 2

私自身は趣味でやっています。
なので、もしかすると解釈自体が間違っている可能性がありますが。

デザインパターンは別に オブジェクト指向に限ったものではないようです。

実際、デザインパターンの骸骨たち (RE-BONE) with Cというサイトでは、C言語で擬似的にデザインパターンをやっています。

( この場合は、クラスではなくて構造体ですが。 )

なので一応、デザインパターンは構造化でも可能だと思います。

Answer 3

デザインパターンという言葉の意味の問題ですね。また、GoFのものが有名ですが、オブジェクト指向において別にこれ以外が存在しないというものではありません。

広義にアルゴリズム全般といえばそれも間違いではありません。さらにいえば、プログラミングに限らず「定石」という一般語として考えればさらに解釈を広げることができます。

Answer 4

まとまったものがあるかどうかは知りませんが、BASIC のような非構造化言語から C のような手続き型言語へプログラマーが移行する際にデザインパターンはいくつも生まれているのではないかと思います。

• 構造化しろ。GOTO はなるべく使うな。
• 同じことを繰り返すな。同じことを二回書くなら手続き(プロシージャ、サブルーチン、関数)を書け。
• グローバル変数を減らせ。ローカル変数を使え。
• 変数やプロシージャ名は一文字のアルファベットでなく分かりやすい物を使え。

オブジェクト指向言語と呼ばれる物の多くは広義の手続き型言語でもある(手続き型言語を内包する)ので、重なる部分も多いのではないかと思います。

Comments

[Zuishin]

ただ、これらに名前がついているかどうかは知りません。名前もなく、まとまってもいないとすると、デザインパターンとは呼べないのかもしれません。

[raccy]

あげている例は、どちかというとコーディング規約や設計哲学と言われるものだと思うのですが、どうなのでしょうか？

[Zuishin]

私はデザインパターンを設計哲学と理解していましたが、回答に書いたこれらがコード全般にわたって使われることを考えると、特定の場面で使われるデザインパターンとは確かに違うかもしれませんね。

Answer 5

こんにちは。

Wikipediaから引用すると

ソフトウェア開発におけるデザインパターン（型紙（かたがみ）または設計パターン、英: design pattern）とは、過去のソフトウェア設計者が発見し編み出した設計ノウハウを蓄積し、名前をつけ、再利用しやすいように特定の規約に従ってカタログ化したものである。

ということは、名前がついているようなアルゴリズムは全て該当すると言っても良いように見えます。
ただ、おぼろげな記憶ですが、確か「アルゴリズムとは、停止して答えを出力する手続き」だったと思います。オブジェクト指向プログラムをアルゴリズムと呼ぶには無理がありそうです。そのため、別の名前で呼ばれているのかも知れません。