
マイケルです!!


下記の書籍をベースにまとめてみました!
Clean Architecture 達人に学ぶソフトウェアの構造と設計 (アスキードワンゴ)


様々な形態のシステムに共通するアーキテクチャのルール、原則
についてまとめた本なんだ!


これから形が変化していっても役立つ知識が得られる本だと思うよ!


この記事も参考にして、気になったら書籍も読んでみてね!

ソフトウェア設計の目的

ソフトウェア設計の目的は
「求められるシステムを構築、保守するために必要な人材を最小限に抑えること」である。
Clean Architecture

開発も運用もスムーズになり、必要な人材やコストも最小限に抑える
ことができます!


下記のように記述されていました!
ソフトウェアはソフトでなければならない。
Clean Architecture

変更が容易なプログラムは長い目で見て利点がありますし、開発途中の変化にも対応することができます!

これを達成するための基本的な原則について紹介します!

変化に強いというのがキーワードなんだクマ
SOLID原則

- 変化に強く、理解しやすい構造を作るための原則
- 多くのソフトウェアシステムで利用できるための原則
- 下記の5つの原則の頭文字を取っている
・単一責任の原則(SRP: Single Responsibility Principle)
・オープン・クローズドの原則(OCP: Open-Closed Principle)
・リスコフの置換原則(LSP: Liskov Substitution Principle)
・インターフェイス分離の原則(ISP: Interface Segregation Principle)
・依存関係逆転の原則(DIP: Dependency Inversion Principle)

かっこいいクマ・・・!!

単一責任の原則(SRP: Single Responsibility Principle)
- モジュールを変更する理由はたったひとつだけであるべきである。

「変更する理由が1つだけであるべき」ということです。



↑複数の責務を負っている状態

・位置、回転情報の更新
・スコアの計算処理
・描画処理
と大きく3つの責務を負っている状態だ。



その場合、Facadeパターンを使用することで呼び出し元を集結させることができるよ!

↑責務ごとにクラスを分割した


Unityではこれらはコンポーネントとして提供しているよ!
オープン・クローズドの原則(OCP: Open-Closed Principle)
- 既存のコードの変更よりも新しいコードの追加によってシステムの振る舞いを変更できるように設計すべきである。



・拡張に対しては開いていて
・修正に対しては閉じている
と表現されているよ。
・拡張に対して開いている
→インターフェース等を用いて、機能が拡張できるように開いているべきである。
・修正に対して閉じている
→単一責任の原則でもあった通り各モジュールは一つの責務を保障しており、
機能追加のために責務を修正すべきではない。
→ただし、バグによる修正は発生する。

これには先ほど出た単一責任の原則で責務ごとにクラス分割してコンポーネントにまとめ、
後に出てくる依存性逆転の原則に沿って外部から隠蔽する必要があるよ。

追加や差し替えができるようになっているべきなのクマね
リスコフの置換原則(LSP: Liskov Substitution Principle)
- 個々のパーツが交換可能となるようにすべきである。


例えば下記のような四角形(RectAngle)クラスがあったとします。

↑四角形クラス



下記のようにメソッドが異なってしまうことになるんだ。
すなわち呼び出し元の処理を変えないといけず置換できないことから
この原則に違反していると言えるよ。

↑長方形クラスは処理が異なってしまう


インターフェイス分離の原則(ISP: Interface Segregation Principle)
- 使っていないものへの依存を回避すべきである。




↑Crudクラスと各オペレーション

どれか一つの処理を修正したら全て再コンパイルしなければなりません。


↑各処理をインターフェースに分離

全て再コンパイルする必要もないクマね

不要な処理に依存していないかを常に意識する必要があります。
依存関係逆転の原則(DIP: Dependency Inversion Principle)
- 具象に依存せず、抽象を参照し依存するべきである。

これは依存性を操作できるというオブジェクト指向のパワーを利用した原則だ!

一体どういうことクマ??

抽象クラスを使用すると依存の方向が逆になるんだ!

↑依存性の矢印が抽象クラスに向いている


下位レベル(詳細)のが、上位レベル(方針)に依存すべきというのがこの原則の意図なんだ。

↑まとまりで考えると本来の依存とは逆になっている

これが依存性を操作できるということなのクマね

満たしていない具象コンポーネントをなるべく少数に絞り込むことが重要になるよ。

この原則を適用している例と言えるね!

↑Abstract Factoryパターン

コンポーネントの原則

SOLID原則の他にコンポーネント設計に焦点を当てた原則も存在します。
コンポーネントの凝集性
・再利用・リリース等価の原則(REP)
→再利用の単位とリリースの単位は等価になる。
・閉鎖性共通の原則(CCP)
→コンポーネントを変更する理由が複数あるべきではない。
・全再利用の原則(CRP)
→使っていないクラスを持つコンポーネントに依存しないようにする。
REPとCCPは包含関係にあり、CRPとは相反する。
これら3つの原則のバランスをとるのが重要である。
コンポーネントの結合
・非循環依存関係の原則(ADP)
→コンポーネントの依存グラフに循環依存があってはいけない。
・安全依存の原則(SDP)
→安定度の高い方向に依存すること。
・安定度・抽象度等価の原則(SAP)
→コンポーネントの抽象度は、その安定度と同程度でなければならない。

クリーンアーキテクチャ

かの有名なクリーンアーキテクチャです!



下位レベル(仕組み)が上位レベル(詳細)に依存するように設計する、というのが根本の考え方です。

ネットで調べてみて下さい!
設計上の注意点

いくつか紹介します!
依存性は下位(詳細)→上位(方針)に向かっていなければならない。
Clearn Architecture

下位から上位に依存するよう意識して設計を行う必要がある、ということですね。

データベース、ウェブ、フレームワークは詳細である。
Clearn Architecture

設計をする際にまずDBやフレームワークから決めてしまうことが多いと思いますが、
これらは本来詳細で差し替え可能となっていることが望ましいです。


フレームワークを使用することは結婚である。
Clearn Architecture

そしてフレームワークの機能に依存してしまうと一生使い続けなくてはならなくなるため、ある意味 結婚する とも例えられます。

何も考えずに使用するのでなく、一旦結婚してもいいのか?を考えるようにしましょう・・・。



おわりに

どうだったかな?

出てきたキーワードを意識して開発してみようと思ったクマ

実際にたくさん書いていくしかなさそうだね

実際にSOLIDコードを書く練習をしてみることにするよ・・・

でも高いクマ・・・・



アデュー!!

【ソフトウェア開発】設計の目的とSOLID原則についてまとめる【クリーンアーキテクチャ】 〜完〜
コメント