Logicの実装デザイン

No more, アバウトLogic!?

よく巨大な Logic を見かけませんか？

e.g. No way, logic should not extend action @Java
public class SeaLogic { // ★名前がアバウト

    // ここにメソッド100個くらい...ってちょっとおおげさだけど、ちょーたくさん
}

大抵、MemberLogic, ProductLogic というアバウトな名前のクラスであることが多いです。 Memberに関するLogicだから、Memberに関するものがなんでも入ります。

こういったクラスがすでに存在していると、後から実装する人は、当然 Member に関するものは MemberLogic に入れます。"ちょっとでかいなぁ、やだなぁ" と思っても、そのまま MemberLogic に入れることがほとんどでしょう。MemberLogic がすでにあるのに、MemberSignupLogic は作りづらいですから。 (すでにあるクラスに入れる方が楽と思うでしょうし...MemberLogicに入れなきゃいけないんだと思うでしょう)

Logicはどういう単位で作っていくべきでしょうか？

これは難題です。恐らくちゃんとやるなら、DDD的なアプローチが必要になるでしょう。 でも、スタートアップではなかなか最初から徹底するのは難しいものです。

でも、Logicを作って再利用はしたい...

少なくとも、モノ + Logic だけのクラスは作らないこと。そう、MemberLogic です。

小さな提案、最低限 モノ + 業務 + Logic にすること。 MemberSignupLogic です。もし、業務自体で暗黙にモノが特定できるなら、業務 + Logic だけでも良いでしょう。SignupLogic ですね。でも、モノ+Logicにはしない。

e.g. object + business + logic @Java
public class SeaInParkLogic { // SeaにInParkするLogic

    // したら、さすがに In する以外のメソッドが追加されることは...あまりないはず
}

PurchaseLogic は迷いますね。Purchaseはモノなのか業務なのか... でも、購入というイベントにも色々なものがあるかと思います。 購入フロー自体に加えて、購入商品の支払い、購入履歴の確認、購入のキャンセルなどなど、購入というデータに対して、様々な振舞いが存在します。 安易に PurchaseLogic を作ると、それらがすべて後からどんどん追加されていきます。

その結果、一つしかメソッドのないLogicができるかもしれませんが、別にそれは構わないかと思います。 インクリメンタル開発では、後で追加される可能性は大ですから。

モノは名詞とは限らないし、業務が動詞とは限りません。 そこが難しいのかもしれませんが、少なくとも Logic を作るときにちょっと考えてみると、良い名前が見つかるかもしれません。

No more, Logic が Action 継承!?

よく新人プログラマーの実装で見かけることがあるかと思います。

e.g. No way, logic should not extend action @Java
public class SeaInParkLogic extends DocksideBaseAction { // ★絶対ダメ
    ...
}

Logic は Action ではありません。つまり、"is a" の関係になっていません。

では、なぜ "is a" の関係になっていないといけないのでしょうか？

Actionのスーパークラスは、Actionに最適化しています。Actionを形づけるために存在しています。 Logicのために存在しているわけではない のです。

ゆえに...

(Actionを継承している)Logicに都合の悪い修正が平気で入ります。

もし、Actionのスーパークラスの修正で、それを継承している Logic が落ちたとしたら、Action を継承している Logic の方が良くないと言えます。

もともとオブジェクト指向の目的として、意味 を重視して、概念ごとにクラスを取り扱うことでプログラムを整備しやすいという点があります。 "XxxLogic は Action である" と自然言語にして しっくりくるかどうか？ ここがポイントです。

便利なメソッドが欲しければ、Logicがその便利なクラスに依存すればよいと考えます。 それが、Actionのスーパークラスにベタッと書いてあったのであれば、別途クラスに抽出して再利用して使うようにしましょう。

一方で、Logicのスーパークラスを作っても悪いわけではありませんが、スーパークラスのメインの役割は その概念を形づける なので、特に Logic を共通的に形づけるものはあまりないかなと考えるので(Actionが非常に定型的で特殊と言えます)、大抵の場合は全体共通のスーパークラスはあまり必要ではないと考えています。 もちろん、まとまった業務単位で必要であれば作っても良いでしょう。

No more, Logic が web に依存!?

もっと、"それ以前" 的な話ですが... 時々見かけるコードにこういうのがあります。

e.g. No way, logic should not depend on web @Java
public class SeaInParkLogic {

    public void land(SeaForm form) { // ★絶対ダメ
    }
}

先の通り、Logicは再利用を目的 にしているため、とある固有の画面のFormクラスを参照すると、別の画面で再利用がしづらくなります。 Formクラスはwebサイドに特化しているので、こちらも先に述べた潜在的にwebに依存したロジックとなってしまいます。

仮に、B画面がA画面のFormをnewして無理矢理再利用したとしましょう。 でも、A画面のFormはA画面に最適化されていて、いかにもA画面だけで使っていそうなクラス名やパッケージに見えます。 でも実はB画面が使っている...となると、B画面やLogicのことを気にせずにA画面都合の修正が入り、B画面やLogicが落ちる というトラブルが発生しやすくなります。ひとりで作っていればそんなことはないだろうと思われるかもしれませんが、インクリメンタル開発では様々な人が入れ替わり立ち替わりコードを修正することが想定されるため、再利用すべきもの再利用すべきでないものは明確にしたいという気持ちがあります。

アーキテクチャ的にも、完全に逆参照となります。

どうしても引数が多くてまとめたい場合は、別途パラメータークラスを作成すると良いでしょう。

e.g. Parameter class for SeaInPark @Java
public class SeaInParkParam {

    public Integer piariId;
    public String dstoreName;
    public LocalDate bonvoDate;
    public LocalDateTime ambaDateTime;
    public Boolean miraco;
    ...
}

e.g. Logic accepts Param @Java
public class SeaInParkLogic {

    public void land(SeaInParkParam param) {
    }
}

e.g. package of parameter class @Directory
app
 |-logic
 |  |-sea
 |  |  |-SeaInParkLogic.java
 |  |  |-SeaInParkParam.java
 |-web
 |  |-sea
 |  |  |-SeaAction.java
 |  |  |-SeaForm.java

概念的な話が難しければ、app.logicパッケージからapp.webパッケージを参照してしまっていないか？ という視点で考えて頂ければと。

Logicは、ずばり ビジネスロジック ということで、極端な話 "バッチのプログラムから呼ばれても大丈夫" というような状態をキープするものです。少なくとも、LastaFluteではそのように想定しています。 なので、Session や Cookie にも依存してはいけません(SessionManager や CookieManager を DI してはいけません)。

e.g. No way, logic should not depend on web @Java
public class SeaInParkLogic {

    @Resource
    private RequestManager requestManager; // ★絶対ダメ
    @Resource
    private SessionManager sessionManager; // ★絶対ダメ
    @Resource
    private CookieManager cookieManager; // ★絶対ダメ
}

どうしても、webに依存した状態で再利用がしたければ、それは ActionAssist を使いましょう。