安定度・抽象度等価の原則(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 を使って、定量的にコンポーネントの分析が可能
この記事が気に入ったらサポートをしてみませんか?