公開かそれとも隠蔽か〜ソフトウェア設計のきほん〜

はじめに

この記事ではソフトウェア設計において

適切に隠蔽や公開ができなければどうなるか
どこをどうやって隠蔽・公開するのか
適切に隠蔽と公開することで何が得られるか

についてまとめました。

動画解説も作ったのでご覧ください

隠蔽と公開が適切でなければ使う側の負担は増加する

まず、私たちの日常生活を例に隠蔽と公開について考えると・・・

炊飯器や電気ケトルなどは

電源を繋いでボタンひとつで

ご飯を炊いたり、お湯を沸かせます。

使う側である僕たちは、

機械がどういう内部構造で、どういう原理で

ご飯が炊けたり、お湯が沸かせるかを理解せずとも、

目的を果たせます。

もし、

電源を繋いで毎回複雑なセットアップが必要だったり、

機械をバラして何かをいじらなければ、

ご飯を炊いたり、お湯が沸かせなかったらどうでしょう？？

私たちが、

炊飯器や電気ケトルの内部構造に詳しくなれるかもしれませんが、

私たちの負担が高く、使い方を間違える危険も高まります。

炊飯ボタン、湯沸かしボタンだけが使う側に公開されて、

機械の内部構造や、

ご飯を炊くまでの細かいステップが隠蔽されている。

と考えることもできます。

これはソフトウェア開発においても同じことが言えます。

使う側が直感的にシンプルに使えるように、

どこをどのように公開したり、隠蔽するかを

慎重に決める必要があります。

もし適切に公開と隠蔽が行えていなければ、

それを使う側の全てが至る所で複雑になり変更に弱くなる
それを使う側が誤用してバグに繋がる可能性が高まる
リファクタリングしずらくなる

こういった事態に陥ります。

外から(使う側)見たときに、

複雑な内部構造や内部の細かい状態を公開してしまうと、

例えばその状態を利用して使う側の方で判定を行い始めたりします。

使う側とはたいていの場合複数あるので、

その判定ロジックは至る所に書かれ、

その結果変更が必要になるとそれらを漏れなく修正しなければならなくなります。

なんでも公開してしまったら・・・

公開の仕方が複雑だったら・・・

また、

外から(使う側)見た時の詳細でしかない部分が、

全然関係ない場所で利用(依存)されるせいで、

外から見た振る舞いそのままに、

内部の処理を最適化しようとしてもしずらくなってしまい、

使う側だけでなく使われる側の視点でも

変更に弱くなってしまいます。

実装の詳細が公開されているコードと適切に隠蔽できているコード比較

ここからは、

具体的に悪い例と良い例をコードで見て比較してみます。

今回のサンプルコードのテーマはワークフローのタスククラスです。

ワークフローのタスク仕様

・タスク開始時のステータスは開始

・customerとoperatorがそれぞれチェック済みになるとステータスは完了

❌ステータスが外から操作可能でタスクが終わってなくてもステータス完了にできてしまう

class WorkFlowTask(
    private var consumerCheck: Boolean = false,
    private var operatorCheck: Boolean = false,
    var taskStatus: TaskStatus = TaskStatus.START // タスクステータスが公開されていて外から参照・更新可能
) {

    fun taskUpdate(consumerCheck: Boolean, operatorCheck: Boolean) {
        this.consumerCheck = consumerCheck
        this.operatorCheck = operatorCheck
        taskStatusUpdate() // タスクの進捗に合わせてステタースも整合性をとって更新する
    }

    private fun taskStatusUpdate() {
        if(consumerCheck && operatorCheck) {
            taskStatus = TaskStatus.COMPLETE
        }
    }

    fun isComplete(): Boolean {
        return TaskStatus.COMPLETE == taskStatus
    }
}


enum class TaskStatus {
    START,
    COMPLETE
}

❌使う側はタスクステータスを更新したり参照して判断したりできてしまう

    
    fun taskExecute() {
        val task = WorkFlowTask()
        task.taskStatus = TaskStatus.COMPLETE
        task.isComplete() // ステータスだけいきなり更新可能(タスク進捗との整合性を破壊できる)

    }

    fun taskCheck(task: WorkFlowTask): Boolean {
        return TaskStatus.COMPLETE == task.taskStatus // ステータスを参照して判断するロジックが作れた
    }

タスクの進捗(operatorやconsumerのチェック)と整合性をとりながら

タスクステータスを更新したいのですが、

タスクステータスを公開しているため、

整合性が取れないような更新ができてしまいます。

さらに、

タスクステータスを外から参照して判断を行うようなロジックを

至る所に作ることが可能になってしまいました。

外から電子回路つついてスイッチ入れることもできる。

けど、手順を誤ると思うように炊飯器が作動しない

といった感じでしょうか。。。

では、

電子回路は外から見えなくしてみましょう。

⭕️内部の詳細を隠蔽することで外から参照・更新を防ぐ

class WorkFlowTask(
    private var consumerCheck: Boolean = false,
    private var operatorCheck: Boolean = false,
    private var taskStatus: TaskStatus = TaskStatus.START // 外から参照・更新できなくなる
) {

    fun taskUpdate(consumerCheck: Boolean, operatorCheck: Boolean) {
        this.consumerCheck = consumerCheck
        this.operatorCheck = operatorCheck
        taskStatusUpdate()
    }

    private fun taskStatusUpdate() {
        if(consumerCheck && operatorCheck) {
            taskStatus = TaskStatus.COMPLETE
        }
    }

    fun isComplete(): Boolean {
        return TaskStatus.COMPLETE == taskStatus
    }
}

⭕️使う側は内部の詳細を気にせず利用できる

    fun taskExecute() {
        val task = WorkFlowTask()
        task.taskUpdate(consumerCheck = true, operatorCheck = true)
        // task.taskStatus = TaskStatus.COMPLETE コンパイル通らない
        task.isComplete()

    }

    // コンパイル通らない
//    fun taskCheck(task: WorkFlowTask): Boolean {
//        return TaskStatus.COMPLETE == task.taskStatus
//    }

内部の詳細であるタスクステータスは

外から参照・更新できなくなりました。(コンパイルエラーになる)

これによって使う側は、

内部の詳細を気にせずシンプルに、

ワークフロータスククラスを利用できるようになり、

タスクの進捗の実態とタスクステータスの整合性は必ずとれるようになりました。

また、

外から内部の詳細を参照できないので、

内部の詳細を利用したロジックが外に染み出る心配もありません。