継承とインターフェイスに関する設計上の混乱

Question

私はかなり独特な設計上の問題に悩まされています。私は、Java ORMを使用していて、次のように私のモデルクラスのいずれかを定義しています

class User extends Model { 
    // . . . 
} 

は今、より多くのモデルがあり、私はそれらすべてのデータの検証をサポートしたいと思います。アイデアは簡単です：各セッターメソッドが呼び出されると、エラーの内部ArrayListが生成され続けます。

エラー処理のメカニズムは、すべてのモデルクラスでまったく同じです。私は、次のインターフェイスを思い描くことができます。

public interface ErrorReportable { 
    ArrayList<String> errors = new ArrayList<String>(); 

    boolean hasErrors(); 

    ArrayList<String> getErrors(); 

    void resetErrors(); 
} 

は、今私は問題を抱えている：すべてのメソッドは抽象的で、私は私のクラスでは、それらのすべての実装を提供する必要がありますを意味しています。これは悲しいことです。これらのメソッドは全く同じ方法で実装されるためです。理想的には、これは私がうまく継承した別のクラスでしたが、悲しいことに、Javaでは多重継承はありません。

私の次のオプションは、インターフェイスのデフォルトメソッドを使用していますが、問題はerrorsフィールドです。これは静的になりますが、各インスタンスには通常のフィールドが必要です。

唯一の解決策のようですが、にhasErrors()メソッドがある必要があります。これはreturn this.error_obj.hasErrors()になります。これはうまくいきますが、私が物事を二度書く必要があるので、私の意見では本当にきれいではありません。

どうすればよいですか？

Answer 1

私はそれだけでList<Error> validate()メソッドを公開するモデルクラスのために良いだろう、とすべてのフィールドを検証し、エラーを収集し、スタンドアローンのバリデータを持っていると思います。

このようにして、収集されたメッセージはモデルの状態の一部ではなく、検証がいつ行われるかを明示的に制御します。コンポジション（ほとんどいつでも良いことです）と必要な唯一の方法モデルクラスで実装するのはエンティティ固有の検証です。

クロスフィールドのバリデーションを追加する必要がある場合は、このデザインをフィールドバリデーションと並行して実行することも非常に簡単です。

Answer 2

私があなたの必要性を得たならば、私はすべてのネイタタリインターフェースを実装し、モデル祖先を拡張する独自のModel-classを実装しますが、依然としてAbstractです。

すべての通常のモデルクラスは抽象モデルクラスから継承し、インタフェースの実装とモデルクラス（第2世代）の継承を継承します。 'instance of'でチェックされているフレームワークであれば、それ以降のモデルクラスでもtrueをチェックします。

抽象クラスは、抽象メソッド/メンバーを持つ必要はありませんが、そのクラスから直接インスタンス化されないように抽象クラスを維持する必要があります。

public abstract class myModel extends Model implements ErrorReportable{ ... } 

public class User extends myModel { ... }