カプセル化により、すべてまたはほとんどすべてのフィールドをプライベートにして、ゲッター/セッターによってこれらを公開するように指示されます。しかし、Lombokなどのライブラリが登場し、1つの短い注釈ですべてのプライベートフィールドを公開できるようになりました@Data。すべてのプライベートフィールドのゲッター、セッター、および設定コンストラクターを作成します。

誰かが私にすべてのフィールドをプライベートとして非表示にし、その後いくつかの余分な技術でそれらのすべてを公開するという意味を説明できますか？なぜパブリックフィールドだけを使用しないのですか？私たちは出発点に戻るためだけに長く困難な道を歩んだと感じています。

はい、ゲッターとセッターを介して機能する他のテクノロジーがあります。そして、単純なパブリックフィールドを介してそれらを使用することはできません。しかし、これらの技術が登場したのは、私たちがそれらの多くの特性を持っているからです-公共のゲッター/セッターの背後にあるプライベートフィールド プロパティがなければ、これらの技術は別の方法で開発され、パブリックフィールドをサポートします。そして、すべてがシンプルになり、ロンボクは今は必要ありません。

このサイクル全体の意味は何ですか？そして、実際のプログラミングではカプセル化は本当に意味がありますか？

すべての属性をゲッター/セッターで公開すると、Cまたは他の手続き言語でまだ使用されているデータ構造のみを取得できます。これはカプセル化ではなく、Lombokは手続き型コードを簡単に使用できるようにしています。単純なパブリックフィールドと同じくらい悪いゲッター/セッター。本当に違いはありません。

また、データ構造はオブジェクトではありません。インターフェイスの作成からオブジェクトの作成を開始する場合、インターフェイスにゲッター/セッターを追加することはありません。属性を公開すると、データの操作がオブジェクトの外部にあり、コードベース全体に広がるスパゲッティプロシージャコードにつながります。これで、オブジェクトと通信するのではなく、データを処理し、データを操作します。ゲッター/セッターを使用すると、データ駆動型の手続き型プログラミングが可能になり、操作はまっすぐに命令的に行われます。データを取得する-何かをする-データを設定する。

OOPでは、正しい方法でカプセル化することは象です。オブジェクトが完全に制御できるように、状態と実装の詳細をカプセル化する必要があります。ロジックはオブジェクト内でフォーカスされ、コードベース全体に広がることはありません。そして、はい-コードのメンテナンス性が向上するため、プログラミングではカプセル化が依然として不可欠です。

編集

議論が進行しているのを見て、いくつかのことを追加したいと思います。

• ゲッター/セッターを介して公開する属性の数と、それをどの程度慎重に行うかは関係ありません。より選択的であっても、カプセル化でコードをOOPにすることはありません。公開するすべての属性は、その裸のデータを命令的な手順で処理する何らかの手順につながります。より選択的にすることで、コードの拡散が遅くなります。それはコアを変更しません。
• はい、システム内の境界では、他のシステムまたはデータベースから裸のデータを取得します。しかし、このデータは別のカプセル化ポイントです。
• オブジェクトは信頼できるものでなければなりません。あなたがする必要がないように、オブジェクトの全体的なアイデアは、責任ある中である受注与えるまっすぐで不可欠です。代わりに、オブジェクトがコントラクトを通じて適切に機能することを行うように依頼しています。演技部分をオブジェクトに安全に委任します。オブジェクトは状態と実装の詳細をカプセル化します。

したがって、なぜこれを行う必要があるのか​​という質問に戻ります。この簡単な例を考えてみましょう。

public class Document {
    private String title;

    public String getTitle() {
        return title;
    }
}

public class SomeDocumentServiceOrHandler {

    public void printDocument(Document document) {
        System.out.println("Title is " + document.getTitle());
    }
}

ここには、ゲッターによって内部の詳細を公開するドキュメントと、オブジェクトの外部で機能する外部プロシージャコードがあります。なぜこれが悪いのですか？なぜなら今はCスタイルのコードしか持っていないからです。はい、構造化されていますが、実際の違いは何ですか？C関数を異なるファイルに名前付きで構造化できます。そして、いわゆるレイヤーはまさにそれを行っています。サービスクラスは、データを操作する一連のプロシージャです。そのコードは保守性が低く、多くの欠点があります。printDocument

public interface Printable {
    void print();
}

public final class PrintableDocument implements Printable {
    private final String title;

    public PrintableDocument(String title) {
        this.title = title;
    }

    @Override
    public void print() {
        System.out.println("Title is " + title);
    }
}

これと比較してください。これでコントラクトが作成され、このコントラクトの実装の詳細がオブジェクト内に隠されました。これで、そのクラスを本当にテストでき、そのクラスはいくつかのデータをカプセル化しています。そのデータでどのように機能するかは、オブジェクトの問題です。今オブジェクトと話すためには、彼に自分自身を印刷するように頼む必要があります。それがカプセル化であり、それがオブジェクトです。OOPを使用すると、依存関係の注入、モック、テスト、単一の責任、および多くの利点を最大限に活用できます。

誰かが私に説明することができますか？すべてのフィールドをプライベートとして非表示にし、その後いくつかの余分な技術ですべてを公開する意味は何ですか？なぜパブリックフィールドだけを使用しないのですか？

感覚は、あなたがそうすることになっていないということです。

カプセル化とは、アクセスするために実際に他のクラスが必要なフィールドのみを公開し、非常に選択的かつ慎重であることを意味します。

デフォルトですべてのフィールドにゲッターとセッターを与えるだけではありません！

これは、JavaBeans仕様の精神に完全に反しています。JavaBeans仕様は、皮肉なことに、パブリックgetterおよびsetterの概念の由来です。

しかし、仕様を見ると、ゲッターとセッターの作成が非常に選択的であり、「読み取り専用」プロパティー（セッターなし）および「書き込み専用」プロパティー（なしゲッター）。

別の要因は、ゲッターとセッターが必ずしもプライベートフィールドへの単純なアクセスではないことです。ゲッターは、任意の複雑な方法で返す値を計算できます。キャッシュすることもできます。セッターは値を検証したり、リスナーに通知したりできます。

だから、あなたは以下のとおりです。カプセル化は、あなたが実際に公開する必要があるだけでその機能を公開意味します。しかし、何を公開する必要があるかを考えず、構文変換に従ってすべてを自由に公開する場合、もちろんそれは実際にはカプセル化ではありません。

問題の核心はあなたのコメントで説明されていると思います：

私はあなたの考えに完全に同意します。しかし、どこかでオブジェクトにデータをロードする必要があります。たとえば、XMLから。そして、それをサポートする現在のプラットフォームは、ゲッター/セッターを介してそれを行うため、コードの品質と考え方が低下します。ロンボクは、それ自体が悪いわけではありませんが、その存在自体が私たちに何か悪いことがあることを示しています。

あなたが持っている問題は、永続データモデルとアクティブなデータモデルを混合しているということです。

通常、アプリケーションには複数のデータモデルがあります。

• データベースと通信するためのデータモデル、
• 構成ファイルを読み取るためのデータモデル、
• 別のアプリケーションと通信するためのデータモデル、
• ...

実際に計算を実行するために使用するデータモデルの上。

一般に、外部との通信に使用されるデータモデルは、計算が実行される内部データモデル（ビジネスオブジェクトモデル、BOM）から分離され、独立している必要があります。

• 独立：すべてのクライアント/サーバーを変更することなく、要件に合わせてBOMのプロパティを追加/削除できるように...
• 分離：すべての計算が不変条件が存在するBOMで実行され、あるサービスから別のサービスへの変更、または1つのサービスのアップグレードがコードベース全体に波及しないようにします。

このシナリオでは、通信レイヤーで使用されるオブジェクトがすべてのアイテムを公開するか、ゲッター/セッターによって公開されることはまったく問題ありません。これらは、不変のない単純なオブジェクトです。

一方、BOMには不変式が必要です。これにより、一般に多くのセッターが使用できなくなります（ゲッターは不変式に影響しませんが、カプセル化はある程度は低下します）。

以下を考慮してください。

Userプロパティを持つクラスがありますint age：

class User {
    int age;
}

User年齢だけではなく、生年月日を設定するために、これを拡大します。ゲッターの使用：

class User {
    private int age;

    public int getAge() {
        return age;
    }
}

int ageより複雑なフィールドを交換できますLocalDate dateOfBirth：

class User {
    private LocalDate dateOfBirth;

    public int getAge() {
        LocalDate now = LocalDate.now();
        int year = ...; // calculate using dateOfBirth and now
        return year;
    }

    // other behaviors can now make use of dateOfBirth
}

契約違反、コード破損はありません。より複雑な動作に備えて、内部表現をスケールアップするだけです。

フィールド自体はカプセル化されています。

今、懸念をクリアするために..

Lombokの@Data注釈は、Kotlinのデータクラスに似ています。

すべてのクラスが動作オブジェクトを表すわけではありません。カプセル化の解除に関しては、機能の使用方法によって異なります。すべてのフィールドをゲッターで公開するべきではありません。

カプセル化は、クラス内の構造化データオブジェクトの値または状態を隠すために使用されます

より一般的な意味では、カプセル化は情報を隠す行為です。を悪用した場合@Data、おそらくカプセル化が破られていると推測しやすいでしょう。しかし、それはそれが目的を持っていないということではありません。たとえば、JavaBeansは一部の人に嫌われています。それでも、エンタープライズ開発では広く使用されています。

Beanを使用しているため、エンタープライズ開発は悪いと結論付けますか？もちろん違います！要件は、標準開発の要件とは異なります。豆を乱用することはできますか？もちろん！彼らはいつも虐待されています！

Lombokはまた@Getter、@Setter独立してサポートします-要件が要求するものを使用します。

カプセル化により、すべてまたはほとんどすべてのフィールドをプライベートにし、ゲッター/セッターによってこれらを公開するように指示されます。

これは、オブジェクト指向プログラミングでカプセル化がどのように定義されるかではありません。カプセル化とは、各オブジェクトがカプセルのようなものであり、その外部シェル（パブリックAPI）がその内部（プライベートメソッドとフィールド）へのアクセスを保護および規制し、ビューから隠すことを意味します。内部を非表示にすることにより、呼び出し元は内部に依存せず、呼び出し元を変更（または再コンパイル）せずに内部を変更できます。また、カプセル化により、呼び出し元が安全な操作のみを使用できるようにすることで、各オブジェクトが独自の不変条件を適用できます。

したがって、カプセル化は情報隠蔽の特殊なケースであり、各オブジェクトは内部を隠し、不変条件を強制します。

すべてのフィールドのゲッターとセッターの生成は、内部データの構造が隠されておらず、不変条件を強制できないため、カプセル化の非常に弱い形式です。ただし、呼び出し元を変更（または再コンパイル）しなくても、データを内部に格納する方法を変更できるという利点があります（古い構造との間で変換できる限り）。

誰かが私にすべてのフィールドをプライベートとして非表示にし、その後いくつかの余分な技術でそれらのすべてを公開するという意味を説明できますか？なぜパブリックフィールドだけを使用しないのですか？私たちは出発点に戻るためだけに長く困難な道を歩んだと感じています。

部分的に、これは歴史的な事故によるものです。1つ目は、Javaではメソッド呼び出し式とフィールドアクセス式が呼び出しサイトで構文的に異なることです。つまり、フィールドアクセスをゲッターまたはセッター呼び出しで置き換えるとクラスのAPIが壊れます。したがって、アクセサーが必要な場合は、今すぐアクセサーを作成するか、APIを解除する必要があります。この言語レベルのプロパティサポートの欠如は、他の最新の言語、特にC＃とEcmaScriptとは対照的です。

Strike 2は、JavaBeans 仕様がプロパティをゲッター/セッターとして定義したことであり、フィールドはプロパティではありませんでした。その結果、初期のエンタープライズフレームワークのほとんどはゲッター/セッターをサポートしていましたが、フィールドはサポートしていませんでした。それは今までに長いです（Java Persistence API（JPA）、Bean Validation、Javaアーキテクチャーfor XMLバインディング（JAXB）、Jacksonすべてがフィールドをサポートするようになりました）、しかし、古いチュートリアルと本は長続きし、誰もが物事が変わったことを認識しているわけではありません。言語レベルのプロパティのサポートがないことは、場合によっては苦痛になりますが（たとえば、パブリックフィールドが読み取られたときに単一エンティティのJPA遅延読み込みがトリガーされないため）、ほとんどのパブリックフィールドは正常に機能します。要するに、私の会社は、REST APIのすべてのDTOをパブリックフィールドで作成しています（結局、インターネット経由で送信されるパブリックはこれ以上ありません:-)。

とは言っても、Lombok's @Dataはゲッター/セッターを生成するだけtoString()ではhashCode()ありequals(Object)ません。

そして、実際のプログラミングではカプセル化は本当に意味がありますか？

カプセル化は非常に貴重またはまったく役に立たない可能性があり、カプセル化されるオブジェクトによって異なります。一般に、クラス内のロジックが複雑になるほど、カプセル化の利点が大きくなります。

すべてのフィールドに対して自動的に生成されるゲッターとセッターは一般的に使いすぎますが、レガシーフレームワークを使用したり、フィールドでサポートされていないフレームワーク機能を使用したりするのに役立ちます。

カプセル化は、ゲッターとコマンドメソッドで実現できます。セッターは単一のフィールドのみを変更することが予想されるため、通常は適切ではありませんが、不変式を維持するには複数のフィールドを一度に変更する必要がある場合があります。

概要

ゲッター/セッターは、カプセル化がかなり不十分です。

Javaでのゲッター/セッターの普及は、プロパティに対する言語レベルのサポートの欠如、および多くの教材やそれらによって教えられているプログラマーにまつわる歴史的なコンポーネントモデルでの疑わしい設計選択に起因しています。

EcmaScriptなどの他のオブジェクト指向言語は、言語レベルでプロパティをサポートしているため、APIを壊すことなくゲッターを導入できます。このような言語では、ゲッターを実際に必要なときに導入することができます。前日ではなく、1日で必要になる場合があります。これにより、はるかに快適なプログラミングが可能になります。

私は確かにその質問を自問しました。

しかし、それは完全に真実ではありません。ゲッター/セッターIMOの普及は、それを必要とするJava Bean仕様が原因です。そのため、オブジェクト指向プログラミングではなく、Bean指向プログラミングの機能です。2つの違いは、それらが存在する抽象化層の違いです。Beanは、システムインターフェースに近い、つまり上位層にあります。それらはオブジェクト指向の基盤から抽象化されるか、少なくとも意図されています-いつものように、物事は十分に頻繁に追いやられています。

Javaプログラミングに遍在しているこのBeanには、対応するJava言語機能が追加されていないのは少し不幸だと思います。C＃のPropertiesコンセプトのようなものを考えています。それを知らない人にとっては、次のような言語構成体です。

class MyClass {
    string MyProperty { get; set; }
}

とにかく、実際の実装の要点は、カプセル化の恩恵を依然として受けています。

誰かが私に説明することができますか？すべてのフィールドをプライベートとして非表示にし、その後いくつかの余分な技術ですべてを公開する意味は何ですか？なぜパブリックフィールドだけを使用しないのですか？スタート地点に戻るためだけに長く困難な道を歩んだと感じています。

ここでの簡単な答えは、あなたは絶対に正しいということです。ゲッターとセッターは、カプセル化の値のほとんど（すべてではない）を排除します。これは、カプセル化を解除するgetおよび/またはsetメソッドがあるときはいつでも、クラスのすべてのプライベートメンバーにアクセッサを盲目的に追加する場合、間違っていると言うことではありません。

はい、ゲッターとセッターを介して機能する他のテクノロジーがあります。また、単純なパブリックフィールドでは使用できません。しかし、これらの技術が登場したのは、私たちがそれらの多くの特性を持っているからです-公共のゲッター/セッターの背後にあるプライベートフィールド。プロパティがなければ、これらの技術は別の方法で開発され、パブリックフィールドをサポートします。そして、すべてがシンプルになり、ロンボクは今は必要ありません。このサイクル全体の意味は何ですか？そして、実際のプログラミングではカプセル化は本当に意味がありますか？

ゲッターはセッターであり、Javaプログラミングではユビキタスです。JavaBeanの概念は、機能を事前に構築されたコードに動的にバインドする方法としてプッシュされたためです。たとえば、アプレットにフォームを作成して（誰でも覚えていますか？）、オブジェクトを検査し、すべてのプロパティを見つけてフィールドとして表示することができます。その後、UIはユーザー入力に基づいてこれらのプロパティを変更できます。開発者としてのあなたは、クラスを書くことを心配するだけで、そこに検証やビジネスロジックを配置します。

サンプルBeanの使用

これ自体はひどい考えではありませんが、私はJavaのアプローチの大ファンではありませんでした。それはちょうど穀物に反している。Python、Groovyなどを使用します。この種のアプローチをより自然にサポートするもの。

JavaBeanがJOBOLを作成したために制御不能になりました。つまり、OOを理解しないJavaで書かれた開発者です。基本的に、オブジェクトはデータの袋に過ぎず、すべてのロジックは長いメソッドで外部に記述されていました。それは普通と見られていたので、これに疑問を呈するあなたや私のような人々は、変人と見なされました。最近シフトを見ましたが、これはアウトサイダーのポジションではありません

XMLバインディングは非常に困難です。これは、おそらくJavaBeansに対抗するための良い戦場ではありません。これらのJavaBeansをビルドする必要がある場合は、実際のコードに近づけないようにしてください。それらをシリアル化レイヤーの一部として扱います。

ゲッターなしでどれくらいできるでしょうか？それらを完全に削除することは可能ですか？これはどのような問題を引き起こしますか？returnキーワードを禁止することさえできますか？

あなたが仕事をする気があるなら、あなたはたくさんできることがわかります。それでは、この完全にカプセル化されたオブジェクトから情報がどのように取得されるのでしょうか？協力者を通して。

コードに質問させるのではなく、物事を行うように指示します。それらも返されない場合、返されるものについて何もする必要はありません。そのため、return代わりに手を差し伸べることを考えている場合は、出力ポートのコラボレーターに手を差し伸べてください。

このように物事を行うことには、利点と結果があります。あなたはただあなたが戻ってきたであろうこと以上のものについて考えなければなりません。それを要求していないオブジェクトにメッセージとして送信する方法を考える必要があります。返されたのと同じオブジェクトを渡すか、単にメソッドを呼び出すだけで十分かもしれません。その思考を行うにはコストがかかります。

利点は、インターフェイスに向かって話をしていることです。つまり、抽象化のメリットを最大限に活用できます。

また、ポリモーフィックなディスパッチも提供します。これは、あなたが言っていることを知っている間は、正確に何を言っているのかを知る必要がないからです。

これは、レイヤーのスタックを一方向に進むだけでよいと考えるかもしれませんが、多態性を使用して、狂った循環依存関係を作成せずに後方に移動できることがわかります。

次のようになります。

class Interactor implements InputPort {
    OutputPort out;
    int y = 0;

    Interactor(OutputPort out){
        this.out = out;
    }

    void accumulate(int x) {
        y = y + x;
        out.showAsImage(y);
    }
}

そのようなコードを作成できる場合は、ゲッターを使用することを選択します。必要な悪ではありません。

これは議論の余地のある問題です（ご覧の通り）。多数のドグマと誤解がゲッターとセッターの問題に関する合理的な懸念と混同されるためです。しかし、要するに、何も問題はなく、@Dataカプセル化を壊しません。

パブリックフィールドではなくゲッターとセッターを使用する理由

ゲッター/セッターがカプセル化を提供するためです。値をパブリックフィールドとして公開し、後でその場で値の計算に変更する場合、フィールドにアクセスするすべてのクライアントを変更する必要があります。これは明らかに悪いことです。オブジェクトの一部のプロパティがフィールドに格納されるか、その場で生成されるか、他の場所からフェッチされるかは実装の詳細であるため、その違いはクライアントに公開されません。ゲッター/セッターセッターは、実装を隠すため、これを解決します。

しかし、ゲッター/セッターが基礎となるプライベートフィールドを単に反映している場合、それは同じくらい悪いことではありませんか？

番号！ポイントは、カプセル化により、クライアントに影響を与えずに実装を変更できることです。クライアントが知る必要も気にする必要もない限り、フィールドは依然として価値を保存するための完全に素晴らしい方法かもしれません。

しかし、カプセル化を破るフィールドからゲッター/セッターを自動生成していませんか？

カプセル化はまだありません！@Data注釈は、基礎となるフィールドを使用するゲッター/セッターペアを記述する便利な方法です。クライアントの観点からは、これは通常のゲッター/セッターのペアのようです。実装を書き直すことにした場合でも、クライアントに影響を与えずにそれを実行できます。したがって、カプセル化と簡潔な構文の両方の長所を活用できます。

しかし、ゲッター/セッターは常に悪いと言う人もいます！

根本的な実装に関係なく、ゲッター/セッターパターンは常に悪いと考える人もいます。オブジェクトから値を設定したり取得したりするのではなく、オブジェクト間の相互作用を、あるオブジェクトが別のオブジェクトに何かを要求するメッセージとしてモデル化する必要があるという考え方です。これは主に、オブジェクト指向思考の初期のドグマです。現在の考え方では、特定のパターン（値オブジェクト、データ転送オブジェクトなど）については、ゲッター/セッターが完全に適切である可能性があります。

カプセル化には目的がありますが、誤用または悪用される可能性もあります。

数十（数百ではないにしても）のフィールドを持つクラスを持つAndroid APIのようなものを考えてください。これらのフィールドをAPIのコンシューマーに公開すると、ナビゲートおよび使用が難しくなります。また、ユーザーは、フィールドの使用方法と競合する可能性のあるフィールドを使用して、好きなことを実行できるという誤った概念をユーザーに与えます。その意味で、カプセル化は、保守性、使いやすさ、読みやすさ、およびクレイジーなバグを回避するという意味で優れています。

一方、PODまたはすべてのフィールドがパブリックであるC / C ++の構造体のような単純な古いデータ型も有用です。Lombokの@dataアノテーションによって生成されるような、役に立たないゲッター/セッターを持つことは、「カプセル化パターン」を維持するための単なる方法です。Javaで「役に立たない」ゲッター/セッターを行う数少ない理由の1つは、メソッドがコントラクトを提供することです。

Javaでは、インターフェイスにフィールドを含めることはできません。したがって、ゲッターとセッターを使用して、そのインターフェイスのすべての実装者が持つ共通のプロパティを指定します。KotlinやC＃などの最近の言語では、プロパティの概念は、セッターとゲッターを宣言できるフィールドとして認識されています。結局のところ、役に立たないゲッター/セッターは、Oracleがプロパティを追加しない限り、Javaと共に生きなければならないレガシーです。たとえば、Ketlinは、JetBrainsによって開発された別のJVM言語であり、Lombokで@dataアノテーションが行うことを基本的に行うデータクラスを持っています。

また、いくつかの例を示します。

class DataClass 
{
    private int data;

    public int getData() { return data; }
    public void setData(int data) { this.data = data; } 
}

これはカプセル化の悪いケースです。ゲッターとセッターは事実上役に立ちません。これはJavaなどの言語の標準であるため、カプセル化が主に使用されます。コードベース全体の一貫性を維持することに加えて、実際には役立ちません。

class DataClass implements IDataInterface
{
    private int data;

    @Override public int getData() { return data; }
    @Override public void setData(int data) { this.data = data; }
}

これはカプセル化の良い例です。カプセル化は、契約（この場合はIDataInterface）を実施するために使用されます。この例のカプセル化の目的は、このクラスのコンシューマーに、インターフェースによって提供されるメソッドを使用させることです。ゲッターとセッターは派手なことは何もしませんが、DataClassとIDataInterfaceの他の実装者の間で共通の特徴を定義しました。したがって、私はこのようなメソッドを持つことができます：

void doSomethingWithData(IDataInterface data) { data.setData(...); }

さて、カプセル化について話すとき、構文の問題も解決することが重要だと思います。カプセル化自体ではなく、カプセル化を実施するために必要な構文について人々が不平を言うのをよく見ます。頭に浮かぶ1つの例は、ケーシームラトリからです（彼の暴言はこちらで確認できます）。

カプセル化を使用するプレイヤークラスがあり、自分の位置を1ユニットずつ移動したいとします。コードは次のようになります。

player.setPosX(player.getPosX() + 1);

カプセル化を行わないと、次のようになります。

player.posX++;

ここで彼は、カプセル化は利点を追加せずにさらに多くのタイピングにつながると主張し、これは多くの場合真実であるが、何かに気付く。引数は、カプセル化自体ではなく構文に反します。カプセル化の概念を欠くCのような言語でさえ、 '_'または 'my'またはそれらがAPIのコンシューマーによって使用されるべきではないことを示すもので接頭辞または固定された構造体の変数をしばしば見るでしょう民間。

問題の事実は、カプセル化により、コードのメンテナンス性と使いやすさが向上することです。このクラスを検討してください：

class VerticalList implements ...
{
    private int posX;
    private int posY;
    ... //other members

    public void setPosition(int posX, int posY)
    {
        //change position and move all the objects in the list as well
    }
}

この例で変数がパブリックである場合、このAPIのコンシューマーは、posXおよびposYを使用するタイミングとsetPosition（）を使用するタイミングについて混乱します。これらの詳細を非表示にすることで、消費者が直感的にAPIをよりよく使用できるようになります。

ただし、構文は多くの言語の制限事項です。ただし、新しい言語には、publiceメンバーの素晴らしい構文とカプセル化の利点を提供するプロパティがあります。MSVCを使用している場合、C ++、さらにはC ++でも、C＃、Kotlinにプロパティがあります。Kotlinの例を次に示します。

クラスVerticalList：... {var posX：Int set（x）{field = x; ...} var posY：Int set（y）{field = y; ...}}

ここでは、Javaの例と同じことを達成しましたが、posXとposYをパブリック変数であるかのように使用できます。ただし、それらの値を変更しようとすると、セッターの本体set（）が実行されます。

たとえば、Kotlinでは、これはgetter、setter、hashcode、equals、toStringが実装されたJava Beanと同等です。

data class DataClass(var data: Int)

この構文により、Java Beanを1行で実行できることに注意してください。Javaのような言語がカプセル化の実装に問題があることに気づきましたが、それはカプセル化自体ではなくJavaの欠点です。

Lombokの@Dataを使用してゲッターとセッターを生成すると言いました。@Dataという名前に注意してください。これは主に、データのみを保存するデータクラスで使用されることを意図しており、シリアル化および逆シリアル化されることを意図しています。ゲームの保存ファイルのようなものを考えてください。しかし、UI要素のような他のシナリオでは、変数の値を変更するだけでは期待される動作を得るのに十分でない可能性があるため、最も明確にセッターが必要です。

カプセル化により柔軟性が得られます。構造とインターフェースを分離することにより、インターフェースを変更せずに構造を変更できます。

たとえば、構築時に基礎となるフィールドを初期化するのではなく、他のフィールドに基づいてプロパティを計算する必要があることがわかった場合は、ゲッターを単に変更できます。フィールドを直接公開していた場合、代わりにインターフェースを変更し、すべての使用サイトで変更を行う必要があります。

カプセル化とクラス設計の問題空間を説明し、最後に質問に答えようとします。

他の回答で述べたように、カプセル化の目的は、コントラクトとして機能するパブリックAPIの背後にオブジェクトの内部詳細を隠すことです。オブジェクトは、パブリックAPIを介してのみ呼び出されることがわかっているため、内部を変更しても安全です。

パブリックフィールド、ゲッター/セッター、またはより高レベルのトランザクションメソッドまたはメッセージパッシングを使用することが理にかなっているかどうかは、モデル化されているドメインの性質に依存します。Akka Concurrencyという本（これは多少古くなっていてもお勧めできます）には、これを説明する例がありますが、ここでは省略します。

Userクラスを考えてみましょう：

public class User {
  private String first = "";
  private String last = "";

  public String getFirstName() {
    return this.first;
  }
  public void setFirstName(String s) {
    this.first = s;
  }

  public String getLastName() {
    return this.last;
  }
  public void setLastName(String s) {
    this.last = s;
  }
}

これは、シングルスレッドのコンテキストでうまく機能します。モデル化されるドメインは人の名前であり、その名前の格納方法の仕組みはセッターによって完全にカプセル化できます。

ただし、これはマルチスレッドコンテキストで提供する必要があることを想像してください。1つのスレッドが定期的に名前を読み取っていると仮定します。

System.out.println(user.getFirstName() + " " + user.getLastName());

そして、他の2つのスレッドが綱引きと戦っており、ヒラリークリントンとドナルドトランプを順番に設定します。それぞれ2つのメソッドを呼び出す必要があります。ほとんどはこれで問題ありませんが、時々ヒラリートランプやドナルドクリントンが通り過ぎるのを見ることがあります。

ロックは名または姓のいずれかを設定している間だけ保持されるため、セッター内にロックを追加してもこの問題を解決することはできません。ロックによる唯一の解決策は、オブジェクト全体にロックを追加することですが、呼び出し側のコードがロックを管理する必要があるため（そしてデッドロックを引き起こす可能性があるため）、カプセル化が解除されます。

結局のところ、ロックによるクリーンなソリューションはありません。クリーンな解決策は、内部をより粗くすることで内部を再度カプセル化することです。

public class UserName {
   public final String first;
   public final String last;
   public UserName(String first, String last) { ... }
}

public class User
   private UserName name;
   public UserName getName() { return this.name; }
   public setName(UserName n) { this.name = n; }
}

名前自体は不変になり、そのメンバーはパブリックになることができます。これは、作成後は変更できない純粋なデータオブジェクトだからです。同様に、UserクラスのパブリックAPIはより粗くなり、セッターが1つだけ残っているため、名前は全体としてのみ変更できます。APIの背後にある内部状態の多くをカプセル化します。

このサイクル全体の意味は何ですか？そして、実際のプログラミングではカプセル化は本当に意味がありますか？

このサイクルで見られるのは、特定の状況に適したソリューションを広範に適用しようとする試みです。適切なレベルのカプセル化には、モデル化されるドメインを理解し、適切なレベルのカプセル化を適用する必要があります。これは、すべてのフィールドがパブリックであることを意味する場合があります（Akkaアプリケーションのように）場合によっては、メッセージを受信する単一のメソッドを除いて、パブリックAPIがまったくないことを意味します。ただし、カプセル化の概念自体は、安定したAPIの背後に内部を隠すことを意味し、特にマルチスレッドシステムでは、大規模なプログラミングソフトウェアの鍵となります。

これが理にかなっているユースケースを考えることができます。元々は単純なgetter / setter APIを介してアクセスするクラスがあります。後で同じフィールドを使用しないように拡張または変更しますが、同じAPIを引き続きサポートします。

幾分不自然な例：デカルトと対として開始ポイントp.x()とp.y()。後で極座標を使用して新しい実装やサブクラスを作るので、あなたも呼び出すことができますp.r()とp.theta()、しかし呼び出すクライアントコードp.x()とp.y()有効です。クラス自体は、内部の極形式から透過的に変換されy()ますreturn r * sin(theta);。つまり、now になります。（この例では、設定するだけであるx()かy()、あまり意味がありませんが、それでも可能です。）

この場合、「フィールドを公開するのではなく、ゲッターとセッターを自動的に宣言するのが面倒でしたか、そこでAPIを壊さなければならなかった」と言うかもしれません。

誰かが私に説明することができますか？すべてのフィールドをプライベートとして非表示にし、その後いくつかの余分な技術ですべてを公開する意味は何ですか？

まったく意味がありません。ただし、その質問をするという事実は、Lombokが何をするのか理解していないこと、およびカプセル化を使用してオブジェクト指向コードを記述する方法を理解していないことを示しています。少し巻き戻しましょう...

クラスインスタンスの一部のデータは常に内部であり、決して公開されるべきではありません。クラスインスタンスの一部のデータは外部で設定する必要があり、一部のデータはクラスインスタンスから戻す必要があります。ただし、クラスの表面下での処理方法を変更したい場合があるため、関数を使用してデータを取得および設定できます。

一部のプログラムは、クラスインスタンスの状態を保存する必要があるため、これらには何らかのシリアル化インターフェイスが含まれている場合があります。クラスインスタンスがその状態をストレージに保存し、その状態をストレージから取得できるようにする関数を追加します。クラスインスタンスはそれ自体のデータを制御しているため、これによりカプセル化が維持されます。プライベートデータをシリアル化している可能性がありますが、プログラムの残りの部分はアクセスできません（より正確には、プライベートデータを故意に破損しないように選択することでチャイニーズウォールを維持します）。逆シリアル化の整合性チェックを実行して、データが正常に戻ったことを確認します。

データには、範囲チェック、整合性チェックなどが必要な場合があります。これらの関数を自分で記述することで、すべてを行うことができます。この場合、私たちはすべて自分でやっているので、ロンボクは必要ありません。

しかし、多くの場合、外部で設定されたパラメーターは単一の変数に保存されます。この場合、その変数の内容を取得/設定/シリアライズ/デシリアライズするために4つの関数が必要になります。これらの4つの関数を自分で記述するたびに速度が低下し、エラーが発生しやすくなります。Lombokでプロセスを自動化すると、開発が高速化され、エラーの可能性がなくなります。

はい、その変数を公開することは可能です。この特定のバージョンのコードでは、機能的に同一です。しかし、関数を使用している理由に戻ります。「クラスの表面下での処理方法を変更したい場合があります...」変数をパブリックにすると、このパブリック変数がインターフェース。ただし、関数を使用する場合、またはLombokを使用してこれらの関数を自動的に生成する場合は、将来いつでも基になるデータと基になる実装を自由に変更できます。

これにより明確になりますか？

私は実際にはJava開発者ではありません。しかし、以下はほとんどプラットフォームに依存しません。

私たちが書いたほぼすべてのものは、プライベート変数にアクセスするパブリックゲッターとセッターを使用します。ゲッターとセッターのほとんどは簡単です。しかし、セッターが何かを再計算する必要がある、またはセッターが何らかの検証を行う、またはプロパティをこのクラスのメンバー変数のプロパティに転送する必要があると判断した場合、これはコード全体に対して完全に非破壊的であり、バイナリ互換性があるため、その1つのモジュールを交換できます。

このプロパティを実際にオンザフライで計算する必要があると判断した場合、それを見るすべてのコードを変更する必要はなく、それに書き込むコードだけを変更する必要があり、IDEがそれを見つけることができます。書き込み可能な計算フィールドであると判断した場合（これを数回行う必要がありました）、それも実行できます。良い点は、これらの変更の多くがバイナリ互換であることです（読み取り専用の計算フィールドへの変更は理論上ではありませんが、とにかく実際に行われる可能性があります）。

最終的には、複雑なセッターを備えた多くの些細なゲッターになりました。また、かなりの数のキャッシングゲッターができました。最終結果として、ゲッターは合理的に安価であるが、セッターはそうでない可能性があると仮定することができます。一方で、セッターがディスクに保持されないことを判断するのに十分な賢明です。

しかし、すべてのメンバー変数をプロパティに盲目的に変更していた男を追跡する必要がありました。彼はアトミックアドが何であるかを知らなかったため、実際にはパブリック変数である必要があるものをプロパティに変更し、コードを微妙に壊しました。

ゲッターとセッターは、開発プロセス中に内部構造またはアクセス要件が変更された場合に将来のリファクタリングを回避するために追加された「念のため」の手段です。

リリースの数か月後に、クライアントは、クラスのフィールドの1つが負の値に設定される場合があることを通知します。パブリックフィールドを使用すると、コードベース全体でこのフィールドのすべての割り当てを検索して、設定する値にクランプ機能を適用する必要があります。このフィールドを変更するときは、常にそれを行う必要があることに注意してください。しかし、それは最悪です。代わりに、ゲッターとセッターをすでに使用している場合は、setField（）メソッドを変更するだけで、このクランプが常に適用されるようにすることができます。

現在、Javaのような「時代遅れの」言語の問題は、この目的のためにメソッドの使用を奨励していることです。これにより、コードが無限に冗長になります。書くのは苦痛で読みにくいので、この問題を何らかの形で軽減するIDEを使用しているのです。ほとんどのIDEは、ゲッターとセッターを自動的に生成し、特に指示がない限り非表示にします。Lombokはさらに一歩進んで、コンパイル時に手続き的に生成するだけで、コードをより洗練された状態に保ちます。ただし、他の最新の言語では、この問題を何らかの方法で単純に解決しています。たとえば、Scalaまたは.NET言語

たとえば、VB .NETまたはC＃では、単純な-副作用なし-ゲッターとセッターを単にパブリックフィールドにするためのすべてのフィールドを作成し、後でプライベートにし、名前を変更し、以前の名前のプロパティを公開することができます必要に応じて、フィールドのアクセス動作を微調整できるフィールド。Lombokを使用すると、getterまたはsetterの動作を微調整する必要がある場合、必要に応じてこれらのタグを削除し、新しい要件で独自のコードを作成できます。他のファイルでは何もリファクタリングする必要はありません。

基本的に、メソッドがフィールドにアクセスする方法は、透明で統一されている必要があります。現代の言語では、フィールドの同じアクセス/呼び出し構文で「メソッド」を定義できるため、これらの変更は開発の初期段階ではあまり考慮せずにオンデマンドで実行できますが、Javaでは事前にこの作業を行う必要がありますこの機能はありません。使用している言語では「念のために」メソッドの時間を節約したくなかったため、Lombokでできることは時間を節約することだけです。

誰かが私にすべてのフィールドをプライベートとして非表示にし、その後いくつかの余分な技術でそれらのすべてを公開するという意味を説明できますか？なぜパブリックフィールドのみを使用しないのですか？出発点に戻るためだけに長く困難な道を歩んだと思います。

ええ、それは矛盾しています。最初にVisual Basicのプロパティに遭遇しました。それまで、私の経験では、フィールドの周りにプロパティラッパーはありませんでした。パブリック、プライベート、および保護フィールドのみ。

プロパティは一種のカプセル化です。Visual Basicのプロパティは、1つ以上のフィールドの出力を制御および操作する方法であり、明示的なフィールドとそのデータ型さえ隠し、たとえば日付を特定の形式の文字列として出力する方法であると理解しました。しかし、それでも大きなオブジェクトの観点から「状態を隠して機能を公開する」ことはありません。

しかし、プロパティは、プロパティゲッターとセッターが分離されているため、正当化されます。プロパティなしでフィールドを公開することは、すべてかゼロでした。それを読むことができれば、それを変更できます。したがって、保護されたセッターを使用して、弱いクラスの設計を正当化できます。

では、なぜ実際のメソッドを使用しなかったのでしょうか？それはVisual Basic（およびVBScript）（oooh！aaah！）であり、大衆向けのコーディング（！）であり、それは大流行でした。したがって、最終的にはばかげた政治が支配した。