unity開発メモ帳

Unityゲーム開発です

SOLID原則のざっくりまとめ:前編

 

 

はじめに

SOLID原則は詳しくは知らなかったのですが、自身の知識不足が顕在化してきたのでまとめてみました。

※あくまでも「ざっくり」まとめているので、正確性に欠ける場合がございます。

 

SOLIDとは

  • Robert C. Martin氏(別名ボブおじさん、Uncle Bob)の論文で紹介された
  • 5つの原則の頭文字を取ってSOLID
  • ソフトウェア設計を柔軟なものにして保守しやすくすることを目的にする

 

具体的な内容

S-単一責任 (single-responsibility)

O-オープンクローズド (open/closed)

L-リスコフの置換 (Liskov substitution)

I-インターフェース分離 (Interface segregation)

D-依存性逆転 (dependency inversion)

 

単一責任原則

単一責任原則とは、ざっくり言えばクラス、メソッドはそれぞれ単一の仕事だけについて保証しなければならないという原則です

 

例えば、自動車クラスを作成したとします。

自動車クラスは動力を得るモーターメソッドから成っています。

そこへ、新幹線クラスが新たに作成されました。

そこで、自動車クラスに使われているモーターメソッドを共通化して実装しました。

モーターメソッドを2個作るのはメンドウなので、こうして1個で済ませられました!

 

しかし、新幹線クラスにとって自動車のモーターは遅すぎるようです。



これで一件落着!!

 

とはならず、自動車クラスは速すぎるモーターのせいで事故ってしまいました、、

この例では、モーターコンポーネントが単一責任原則に違反しています。コンポーネントが2つ以上の仕事の責任を一度に受けているためです。

 

この例のように、「それぞれのクラス、メソッド等が単一の仕事を保証すること」=単一責任原則 を満たすことができなければ、一度の変更が思いも寄らない事故を引き起こす可能性があります。

 

オープンクローズドの原則

オープンクローズドの原則とは、ざっくり言うと要素を追加する際、元のコードを「書き直さず」、元のコードを「拡張」して実装できるようにしなければならないという原則です。

 

例えば、貨物列車を作ったとします

そこへ、客車を追加したいという要望が出てきました。

もし、貨物列車の最後尾に客車を何かしらの金具でつなげることができれば、既存の貨物車両を改造するよりも効率的です。

このように、オープンクローズドの原則を用いれば、あとになって追加される要素に必要な労力が少なく済みます。

さらに、既存のコードを改造したことで発生するバグの数も抑えることができます(本当にざっくりですが)

 

 

リスコフの置換原則

リスコフの置換原則とは、ざっくり言うと継承によってできた派生型(サブクラス)は、その基底型(スーパークラス)と置き換え可能でなければならないという原則です

 

例えば、新しく大工クラスを作ったとします。大工クラスは建築に関わるメソッドを持っています

その大工クラスを継承した弟子クラスが作成されました。

しかし、弟子クラスは大工クラスを継承したにも関わらずパティシエとなってしまいました。

そんな事情を知らない人は彼に大工の仕事を頼み、パティシエの仕事は頼まないでしょう。

 

このようにリスコフの置換原則に違反すると、クライアント側でそのサブクラスが何をできるのかがわかりにくく、使われなくなってしまうようになります。

また、「大工の継承者だから大工の仕事を頼んだのに全然働いてくれないよ!!」というように、サブクラスで本来できることができないために、思わぬ事故が起きる可能性もあります。

 

続く

fatena.hatenablog.com

 

 

 

 

参考

ボブおじさんのブログ

https://blog.cleancoder.com/

 

wiki

https://ja.wikipedia.org/wiki/SOLID

 

単一責任原則について

単一責任原則で無責任な多目的クラスを爆殺する - Qiita

 

オープンクローズドについて

5分で理解するオープン・クローズドの原則 - Qiita

 

リスコフの置換原則について

【オブジェクト指向】「リスコフの置換原則」について | プログラミングマガジン

その7 参照オブジェクトの正体は気にしない原則 : LSP