構造化手法とオブジェクト指向

オブジェクト指向レス開発 via PM見習いの読書日記
まずコメントする前に、個人的には業務系システムの経験は皆無だということを断っておく。
内容的にはソフトウェア開発全般を考慮して書いているので、特に業務系だとかは意識してないが、的外れな点があったら、コメントでご指摘ください。
さて本題。

基本的に構造化手法で物事を考えるのです。構造化では解決できないものについて、オブジェクト指向を導入します。オブジェクト指向だけでは解決できないものについて、仕方がないのでデザインパターン適用を考えます。

基本的に構造化手法で考えるのには同意。でも、構造化で解決できないものにオブジェクト指向を導入するのではなく、構造化手法にオブジェクト指向の考え方を組み合わせることでよりよい設計を考える、というのが適切だ。
そもそもオブジェクト指向というのは構造化手法とはまったく別のものではなく、オブジェクト指向は構造化手法を包含している。構造化手法とは何かというを思い出してみよう。構造化手法とは、以下の4つのアプローチからプログラムを構築することだ。

• 順番に処理を記述するシーケンス
• 分岐条件を記述する制御構文
• 反復処理を記述する反復構文
• 階層的に機能の木構造を作る詳細化

見れば分かるとおり、この4つのアプローチはオブジェクト指向にも含まれていることは明らかだ。
オブジェクト指向はこれらのアプローチに加え、クラスとインスタンスの概念や、継承と多態といった考え方を新たに導入した。アプローチが増えたということは、よりよいプログラムを構築するための選択肢が増えたのだから、歓迎すべきである。
引用する箇所が前後するが、ここにもコメントしておく。

そして 規模が大きければ大きいほど、重要度の相関関係が指数的なものになり 構造化の重要度は ますます向上します。

「規模が大きければ大きいほど」という話であれば、オブジェクト指向的にはアーキテクチャパターンの適用を検討すべきではないかと思う。システムをサブシステムに分割する場合を考えてみよう。構造化手法では機能的側面にのみ着目してサブシステムへの分割を検討する。それに対して、オブジェクト指向では、例えばオブジェクト(サブシステム)の責務といった、機能的側面とは異なる点にも着目できる分だけアプローチの仕方が増えている。
「構造化の重要度は ますます向上」と書かれているが、オブジェクト指向の新しい考え方ばかりに目を奪われて、もともとのアプローチだった構造化手法の考え方で分析するのを忘れているのが問題なのだ。
世間では、オブジェクト指向で導入された新しいアプローチは良くて、構造化手法にもあった歴史のあるアプローチは悪だとでも認識されているのだろうか？
さて、さらに前の部分を引用する。

「失敗オブジェクト指向」にしてしまわない近道の一つは、「構造化」の導入であると私は確信しています。というか、そもそもオブジェクト指向においても 「構造化」にまつわる概念は存在しているのですが、多くの文献や記事においては 「構造化手法」の側面は かなり薄っぺらくしか扱われていないように考えます。

現実はそのとおりだと思う。なぜなら、オブジェクト指向の文献や記事を書く人たちの頭の中では、構造化手法はすでに暗黙知として組み込まれているのである。今さら言うまでもないが、構造化手法を理解することは、ソフトウェア開発者の常識だ。構造化手法を知らずにオブジェクト指向を理解しようというのは、基礎を身に付けないまま高等テクニックに挑戦しようとしているようなものだ。
構造化手法の時代からある機能的な詳細化は、多くの局面でほぼ正しいやり方であることは間違いない。しかし機能的詳細化だけだと、分類しにくい部分がどうしても発生してくる。それを解決してくれるのがオブジェクト指向だ。
例えば、ある機能と別の機能を接続するための部分は、どちらの機能に入れるべきか迷いやすい点だ。オブジェクト指向的に考えれば、単純に接続するのを目的とした Observer や Adapter であったり、または異なる機能に共通する抽象であったりする。
オブジェクト指向は、構造化手法での詳細化では設計しにくかった部分に対して明確な分析を与えてくれる。構造化手法の考え方では結合をなくせなかった部分を完全に切り離してくれる。オブジェクトに責務を与えることによって、責任範囲と依存関係を明確にしてくれる。
オブジェクト指向で新たに導入されたアプローチを利用しなくてもそれなりの設計は可能である。でも、よりよい設計をするためにはオブジェクト指向で導入されたアプローチは必須である。利用しないとか利用させないというのは、よりよい設計を放棄しているのに他ならない。