ビジネスロジックをPOJOデシリアライゼーションデザインパターンから分離
POJOに逆シリアル化しようとしているJSONファイルがあります。
public abstract BaseClass {
private String baseClassField;
abstract String execute();
}
ClassAはBaseClassを拡張します
public ClassA extends BaseClass {
private String classA;
private SomeInterface interface;
@Override
public String execute() {
return interface.execute();
}
}
ユースケースを簡略化しましたが、クラスを構造化した方法でわかるように、コアPOJO定義内にビジネスロジックがあります。すぐに、実行を支援し実行するために他のメンバーインスタンスの依存性注入を取り入れようとするので、それは良い考えではないと思います。
継承階層をメインにし、子クラスが基本クラスで定義されたコントラクトを実行できるようにするには、クラスをどのようにモデル化すればよいですか？
コアPOJO定義内にビジネスロジックを含めます。すぐに、実行を支援し実行するために他のメンバーインスタンスの依存性注入を取り入れようとするので、それは良い考えではないと思います。
データ転送オブジェクトとビジネスクラス（ドメインモデルとも呼ばれる））。 「POJO」は、データ転送オブジェクトの役割を果たします。これは重要なことです。一方がもう一方を参照すると、それらは結合されます。他への参照を保持している限り、それらを分離することはできません。
実際、ビジネスクラスにはPOJOのデータが必要です。これらを分離しておくには、これら2つの異なる種類のクラスに結合することを唯一の目的とするオブジェクトを導入する必要があります。これにより、さまざまなデータアクセスパターンが表示されます。より一般的なものの1つは、リポジトリパターンです。ファイルからデータをロードする方法を知っており、適切なパーサーにデリゲートします。結果のPOJOを受け取り、それらをビジネスクラスにマッピングします。
これにより、POJOはビジネスクラスへの参照がなくなり、ビジネスクラスはPOJOを認識しなくなります。これは永続性無視であり、データの格納方法と取得方法を変更しても、ビジネスクラスを変更せずに維持できる非常に重要な概念です。
各リポジトリは、ビジネスクラスと同じモジュールで定義されたインターフェイスを実装する必要があります。これにより、ビジネスおよびその他のコアサービスクラスは、リポジトリインターフェイスのメソッドを呼び出してデータを取得できるため、永続化メカニズムを知らないままにすることができます。
ドメインモデル： https://en.m.wikipedia.org/wiki/Domain_model
データ転送オブジェクト： https://en.m.wikipedia.org/wiki/Data_transfer_object