はじめに

オブジェクト指向設計について講義を受けており、知識をまとめるために本記事を執筆しました。

そもそも"設計"は何のために？

設計の目的：コスト削減
何をすること？：分割と結合を考える

例え話として、100という規模のソフトウェアを開発をするとする。
仮定的に、工数は規模の２乗だとする。
規模100のまま開発すれば100^2 = 10,000の工数になる。
しかし10の規模10個に分けてやれば、　10^2 * 10 = 1,000の工数になる。
（※結合コストなどは考えていない）
1/10に工数を減らせる。

このように「分割と結合によってコスト削減のアイディアを練る」のが、本来の設計の目的になる。

設計で考えるコスト

さて、このとき設計で考えるコストには２種類ある。

イニシャルコスト(開発コスト)
ランニングコスト(保守コスト)

両方同時に下げることは難しい場合が多い。

各コストを下げたいのはどんな場面だろう？

イニシャルコストを下げたい場面: この世に存在していない全く新しいシステムやサービスを作る場面; 理由：ガッツリ開発コストをかけて開発したのにコケたら困るから
ランニングコストを下げたい場面: すでに存在しているものを作りかえる場面; 理由：ランニングコストを下げながら、長く変化に耐えて欲しいから

コスト削減のための設計手法例

各コスト削減に適した設計手法の例を挙げる。

構造化設計

構造化設計では
・ユーザーのUIへの入力
・イベント
・データアクセス
・イベント
・ユーザー(UI)
この順で設計を考える。
外側(仕事・業務の流れ)から構造の中身を考えるOutside-In principleである。

メリット: わかりやすい=開発コストが抑えられる
デメリット: 変更に弱い=保守コストが上がる

人間が触れる目に見える部分から中身へという順番で考えるので、何より分かりやすい。従って開発コストを抑えやすい。

しかし、最も頻繁に変更されるのはUIという外側から見える部分である。
構造化設計はUIから中身を考えているので、UIを変更した場合、変更しなければいけない範囲があちこちに及びやすい。従って変更に弱い。

オブジェクト指向設計

構造化設計Outside-In principleに対して、オブジェクト指向設計はInside-Out principleである。
つまり、中身を決めた後にUIを考えるという設計である。

メリット: 変更されがちな外部(UI)の変更があっても、UIの変更だけで済む=保守コストが抑えられる
デメリット: やや難しい=開発コストが上がる

オブジェクト指向では、"ビジネスロジック","ルール","常識"などを、言語やコードにする。
その言語・コードが「データの扱い方」であり、このデータの扱い方＋データアクセスが「中身」である。
この常識をコードにするのが慣れるまでは難しい。

構造化設計ではUIから中身を考えるので、UIの変更があると中身も変えなければならない。
しかしオブジェクト指向では中身を考えた後にUIを考えるので、変更されがちな外部（UI)の変更があってもUIの変更だけで済む。
これがオブジェクト指向が「仕様変更に強い」設計である理由だ。

おわりに

「構造化設計よりオブジェクト指向設計が優れている」というわけではない。
オブジェクト指向には常識やルールを言語化するという人間の直感に反した不慣れな作業があり、開発コストが上がってしまうというデメリットがある。
これから新しいサービスを作るという場面では構造化設計を使って作り、軌道に乗ればのちのちオブジェクト指向設計に変えていくというのがよさそうだ。

どの設計が優れているというのではなく、適材適所で使い分けていくのが大切そうだ。

以上となります。お読みいただきありがとうございました！
もし見解の違い等あれば、教えていただけると幸いです。