#エンティティメンバー宣言の場所(Javaコード規則)

Java static code analysis: The members of an interface or class declaration should appear in a pre-defined order

Oracleで定義されたクラスのメンバー宣言の順序は次のとおりです.

クラス変数→インスタンス変数→ジェネレータ→メソッド

例

@Entity
@Getter
@NoArgsConstructor(access = AccessLevel.PROTECTED)
public class Comment extends BaseEntity {

    @Id
    @GeneratedValue
    @Column(name = "comment_id")
    private Long id;

    private String content;

    private int depth;

    private Long bundleId;

    private Long bundleOrder;

    private boolean existsCheck;

    @ManyToOne(fetch = FetchType.LAZY)
    @JoinColumn(name = "user_id")
    private User user;

    @ManyToOne(fetch = FetchType.LAZY)
    @JoinColumn(name = "post_id")
    private Post post;

    @Builder
    public Comment(String content, int depth, Long bundleId, Long bundleOrder, boolean existsCheck, User user, Post post) {
        this.content = content;
        this.depth = depth;
        this.bundleId = bundleId;
        this.bundleOrder = bundleOrder;
        this.existsCheck = existsCheck;
        this.user = user;
        this.post = post;
    }

    public void updateComment(String content){
        this.content = content;
    }

    public void removeComment(){
        this.existsCheck = false;
    }
}

#エンティティでのロムフォードの使用

停止@Data

多くの機能をサポートしていますが、諦めたいSetterが含まれています.

また、ToStringはループリファレンスの問題を引き起こす可能性があります.

停止@Setter

ドメイン名の開発の観点からagrigatの一貫性を破る主な原因である.
すなわち,アグリゲート内部状態の変化はアグリゲートゲンオブジェクト内に凝集しなければならない.

setXXXメソッドは重要ドメインの意味や意図を表すことができません.

ドメインロジックは、ドメインオブジェクトではなく表示レイヤとアプリケーションレイヤに分散し、コードを維持するために多くのリソースを浪費します.

@NoArgsConstructor(access = AccessLevel.PROTECTED)

これはエラージェネレータを自動的に生成するツールです.

デバッガが必要なのは、JPAで遅延ロードを使用する場合にエージェントオブジェクトが必要なためです.
このプロキシオブジェクトは、実際のエンティティを継承して作成する必要があります.すなわち,継承を得るためには,親のポーリングジェネレータを子クラスから呼び出すことができる必要があるため,コンストラクタが必要である.

アクセス権が少ないほど良いです.保護されたフェースエージェントオブジェクトの作成に問題はありません.(不明なオブジェクトを作成しない)

また,@AllArgConstructorを何の考えもなく書きましたが,これはすべてのフィールドを持つジェネレータを生成するのにほとんど必要ないと思います.(自動的に生成されるPK値があるため)
つまり、必要でない場合は使わないということです.

@Builder

このツールをクラスレベルで使用するか、メソッド(ジェネレータ)レベルで使用するかを考慮しました.

@Builderをジェネレータに宣言した方が良いと結論しました.

クラスレベルで使用すると、@AllArgConstructorのようにすべてのフィールドのパラメータを受信するジェネレータが作成されます.自動的に生成されたPK値またはレビューによって自動的に生成されたcreateDate、lastModifiedDate値、または転送する必要のないデータについても、値を受信できます.これは人類の誤りを引き起こす可能性がある.

クラスレベルで使用すると、@AllArgConstructorが強制されます.ビルダーを使用してbuild()で最後にすべてのフィールドに存在するジェネレータを呼び出すため、@AllArgConstructorがない場合はエラーが発生します.

生成者に@Builder宣言を宣言して使用します.

💡 開発には正解がない.つまり、以上の内容は正解ではなく、私の主観的な考えです.