はじめに

バックエンドエンジニアのロードマップに沿ってエンジニアとしての自己肯定感を養うシリーズです。

※現場で役立つシステム設計の原則を元に記事を作成しています。

業務ロジック

メソッドをロジックの置き場所にする

現場で役立つシステム設計の原則では、“従来"という表現をされていますが、手続き型と呼ばれている設計ではデータクラスと機能クラスに分けて表現します。

その名の通りデータクラスはデータを格納して、機能クラスはデータクラスのデータを判断、加工、計算するといった使い方です。

この手続き型の問題は、拡張するときの変更箇所の特定に時間がかかるということです。

なぜかというと、データクラスが参照できるクラスであれば、アーキテクチャのどのレイヤーにでもロジックが書けてしまうからです。

便利のようには見えますが、先に言った変更箇所の特定に時間がかかるこの方法は最善ではありません。

解決としては、Java 本来のクラスの使い方を踏襲することです。

データとロジックを 1 つのクラスに閉じてしまおうという考え方です。

class PersonName {
  private String firstName;

  private String lastName;

  String fullName() {
    return String.format("%s %s", firstName, lastName);
  }
}

データであるfirstNameとlastName、そしてロジック(メソッド)のfullName()が同じクラス内にあります。

こうするとクラス内でデータを扱うことができて変更もこのクラス内で閉じることができます。

また、メソッドはクラス内のインスタンス変数(firstNameやlastName)を使って何らかの処理を行う用途で作成します。

クラスが肥大化したら小さく分ける

これもやってしまいがちですが、改修を繰り返していくうちに、クラスが大きくなっていきます。

大きくなったクラスは手続き型同様に変更箇所の特定に時間がかかります。

それを防ぐために、大きくなってしまったクラスを次のルールで細分化します。

  • インスタンス変数とメソッドを対応付ける
  • メソッドが全てのインスタンス変数を使うようになる

細分化したクラスはそれぞれ独立性が高くなるので、別のクラスで使う時にも再利用ができるようになります。

こうした関連の強いデータとロジックをまとめたクラスを凝集度が高いと言います。

凝集度が高いクラスは、変更箇所もそのクラスに閉じることになるので、疎結合になり他への影響が少なくて済みます。

まとめ

時すでに遅しと言いますか、現場での反省点をつらつら振り返ってベストプラクティスを学んでいるという感じです。

次回に活かそうというモチベーションは上がるのでいい復習方法だと感じます。

備考

現場で役立つシステム設計の原則

表紙イラスト：Loose Drawing