POJOのJavaデザインコンセプト

Question

私は、Java POJOの最適なデザインコンセプトを理解しようとしています。私はそうのようなcarオブジェクトを持っていた場合：

public class Car { 
    private String color; 
    private String make; 
    private String model; 
    private int year; 

    public Car(String color, String make, String model, int year) { 
     this.color = color; 
     this.make = make; 
     this.model = model; 
     this.year = year; 
    } 

    public String getColor() { 
     return color; 
    } 

    public void setColor(String color) { 
     this.color = color; 
    } 

    public String getMake() { 
     return make; 
    } 

    public void setMake(String make) { 
     this.make = make; 
    } 

    public String getModel() { 
     return model; 
    } 

    public void setModel(String model) { 
     this.model = model; 
    } 

    public int getYear() { 
     return year; 
    } 

    public void setYear(int year) { 
     this.year = year; 
    } 
} 

は、この車のPOJOはgetGasMileageまたはgetTirePressureのようなその中の複数のメソッドを持つべきか、これらの方法はCarオブジェクトにかかるユーティリティ/インターフェースの内側に配置する必要がありますか？

これは、getGasMileageのようなメソッドを含むEntityオブジェクトを持つドメイン駆動型デザイン（DDD）を使用して、現在のコードベースに基づいて設計された質問です。 pojo/entityにgetter/setterコードのみが含まれているか、他のメソッドも含まれていることをお勧めしますか？

Answer 1

POJOには、この用語を発明したMartin Fowlerに従ったビジネスロジックが含まれています。

レベッカ・パーソンズ、ジョシュマッケンジーと私は我々がするのではなく、通常のJavaオブジェクトへのエンコーディングのビジネスロジックの多くの利点を指摘された講演では2000年9月の会議で講演のために準備をしている間用語は、鋳造されましたエンティティBeanを使用します。私たちは、人々がシステム内で通常のオブジェクトを使用することに反対している理由を疑問に思っていました。単純なオブジェクトには名前がないためだと結論付けました。だから私たちは1つを与え、それは非常にうまくキャッチします。

POJOはしばしばJava Beanとコンフリクトするため、混乱が発生します。参照：What is the difference between a JavaBean and a POJO?