見出し画像

安定度・抽象度等価の原則(SAP)を開発に活かす


はじめに

今回は安定度・抽象度等価の原則の解説をします。

SOLID のような原則系ですが、SOLID とは違いコンポーネントレベルの原則です。SOLID はクラス単位に適用される、もう少し狭い範囲の原則です。

安定度・抽象度等価の原則とは

コンポーネントの抽象度は、その安定度と同程度でなければいけないという原則です。

安定したコンポーネントはその分抽象的でないといけません。

なぜでしょうか。
その理由は、安定しているということはその分柔軟性に欠けるからです。
これはトレードオフなので致し方ありません。
逆に、不安定であるということはその分柔軟であるということです。

安定したコンポーネントはどうしても柔軟性に欠けてしまうので、どうにかしてより簡単に変更できるようにしたいと思うわけです。

その方法は、インターフェースや抽象クラスを使って開放閉鎖の原則(OCP)に則ることです。

開放閉鎖の原則を使えば、比較的簡単に変更することができます。

また、安定依存の原則(SDP)とも関連が強く、この原則と合わせると、抽象度が高くなる方向に依存すべきという主張になります。

安定度・抽象度等価の原則をどう使うか

安定依存の原則(SDP)で紹介した安定度 I と、これから紹介する抽象度 A を使ってコンポーネントの健康状態が分析できます

抽象度 A = Na ÷ Nc

Na とは、コンポーネント内の抽象クラスとインターフェースの総数です。
Nc とは、コンポーネント内のクラスの総数です。

A が 0 だったら最も抽象的なコンポーネントで、1 だったら最も具体的なコンポーネントです。

不安定さを示す I と、抽象さを示す A を使って、定量的にコンポーネントの分析が可能です。

安定度・抽象度等価の原則に則ると、( I, A) が ( 0, 1 ) であったり ( 1, 0 ) であるべきということです。

もちろん完全に 0 と 1 のどちらかというわけでもないので、( 0.5, 0.5 ) などでも問題ないでしょう。

逆に、( 1, 1 ) や ( 0, 0 ) だと問題だということです。

前者は、抽象的なのに不安定という状態です。
これは実装されないまま放置されているインターフェースなどです。
不要ですね。

後者は、具体的なのに安定している状態です。
これは様々な場所から依存されている具象クラスです。
変更が難しいのでかなりつらい保守になることが予想されます。

まとめ

  • 安定度・抽象度等価の原則とは、コンポーネントの抽象度は、その安定度と同程度でなければいけないという原則

  • 不安定さを示す I と、抽象さを示す A を使って、定量的にコンポーネントの分析が可能

この記事が気に入ったらサポートをしてみませんか?