メソッドの名前を変更してもカプセル化を維持できますか？

ゲッター/セッターが正当化される時期についてこのページを読んでいましたが、OPは次のコードサンプルを提供しました。

class Fridge
{
     int cheese;

     void set_cheese(int _cheese) { cheese = _cheese; }
     int get_cheese() { return cheese; }
 }

void go_shopping(Fridge fridge)
{
     fridge.set_cheese(fridge.get_cheese() + 5);        
}

受け入れ答えの状態：

ちなみに、あなたの例ではFridge、putCheese()andのtakeCheese()代わりに、クラスに and メソッドを指定get_cheese() しset_cheese()ます。その後、まだカプセル化されています。

カプセル化は、名前をget / setからputCheese()/に変更することによってどのように保持さtakeCheese()れますか？

同じ答えでそれはまた述べています：

ゲッターとセッターを使用しても、カプセル化が壊れることはありません。カプセル化を解除するのは、何も考えずに、すべてのデータメンバー（Java lingoのすべてのフィールド）にゲッターとセッターを自動的に追加することです。

この場合、変数は1つだけなのでcheese、チーズを取り出して冷蔵庫に戻したい場合があるため、この場合の取得/設定ペアは正当化されます。

ポイントが足りないと思います。これは、setterとgetterの名前を変更する必要があると言っているのではなく、冷蔵庫からアイテムを追加および削除するメソッドを用意するためのものです。すなわち

public class Fridge
{
    private int numberOfCheeseSlices;

    public void AddCheeseSlices(int n)
    {
         if(n < 0) { 
             throw new Exception("you cant add negative cheese!");
         }
         if(numberOfCheeseSlices + n > this.capacityOfFridge) { 
             throw new Exception("TOO MUCH CHEESE!!");
         }
         ..etc
         this.numberOfCheeseSlices += n;
    }
}

これでプライベート変数がカプセル化されました。必要なだけに設定することはできません。メソッドを使用して冷蔵庫にチーズのスライスを追加および削除することしかできません。これにより、必要なチーズビジネスロジックルールが適用されることが保証されます。

定義により、ゲッターとセッターは毎回カプセル化を解除します。どのような可能性があると主張することは、時には我々はそれを行う必要があるということです。それが邪魔にならないうちに、ここに私の答えがあります：

カプセル化の名前をget / setからputCheese（）/ takeCheese（）に変更することで、カプセル化はどのように保存されますか？

違いは意味論、つまりあなたが書くものの意味にあります。カプセル化は、保護するだけでなく、内部状態を隠すことも目的としています。内部状態は外部でさえ知られているべきではなく、オブジェクトはその状態を操作/使用するためのビジネス関連のメソッド（「動作」と呼ばれることもあります）を提供することが期待されています。

だから、getおよびset技術的な用語でありながら、「冷蔵庫」ドメインとは何の関係もないように見えるputし、take実際にいくつかの意味をなすかもしれません。

しかし、かどうputかtake作る実際の感覚はまだ要件に依存し、客観的に判断することはできません。次のポイントを参照してください：

この場合、変数はチーズ1つだけなので、チーズを取り出して冷蔵庫に戻したい場合があるため、この場合の取得/設定ペアは正当化されます。

これは、より多くのコンテキストなしでは客観的に決定することはできません。あなたの例はgo_shopping()どこかにメソッドを含んでいます。それFridgeが目的である場合、それが必要としないgetかset、または必要とするものですFridge.go_shopping()。このように、要件から派生したメソッドがあり、必要なすべての「データ」はローカルであり、薄いベールに覆われたデータ構造ではなく実際の動作があります。

覚えておいてください、あなたは一般的で再利用可能なを構築していませんFridge。あなたはFridgeあなたの要件のためだけに構築しています。それを必要以上のものにするために費やしたどんな努力も、実際には無駄です。

これのほとんどすべては、カプセル化の基本的な誤解と、それがどのように適用されるかを示しています。

カプセル化を解除していた最初の応答は、間違っています。アプリケーションでは、増加/減少または追加/削除するのではなく、単純に冷蔵庫でチーズの値を設定する必要がある場合があります。また、属性にアクセスしたり属性を変更したりする必要がある場合でも、セマンティクスではなく、属性を提供することでカプセル化を壊すことはありません。最後に、カプセル化は実際には「非表示」ではなく、クラスの外部で公開または操作する必要のない状態と値へのアクセスを制御すると同時に、内部で利用できるようにするタスクにタスクを許可して実行することです。

値を取得または設定する正当な必要性がある場合、ゲッターまたはセッターはカプセル化を解除しません。これが、メソッドを公開できる理由です。

カプセル化とは、データとそのデータを直接変更するメソッドを1つの論理的な場所であるクラスに保持することです。

この特定のケースでは、アプリケーションでチーズの値を変更する必要があることは明らかです。これがどのように行われるかに関係なく、メソッドがクラスにカプセル化されている限り、get / setまたはadd / removeを使用して、オブジェクト指向スタイルに従っています。

明確にするために、メソッド名や論理的な実行に関係なく、アクセスを提供することによってカプセル化がどのように壊れるかの例を示します。

冷蔵庫に「寿命」があるとしましょう。冷蔵庫が機能しなくなるまでの数のティックだけです（議論のために、冷蔵庫は修理できません）。論理的には、ユーザー（またはアプリケーションの残りの部分）がこの値を変更できるようにする方法はありません。プライベートにする必要があります。「isWorking」と呼ばれる別のパブリック属性を介してのみ表示されます。有効期限が切れると、冷蔵庫は内部でisWorkingをfalseに設定します。

ライフタイムカウントダウンの実行とisWorkingスイッチの切り替えはすべて冷蔵庫の内部で行われ、外部でプロセスに影響を与えることはできません。isWorkingは表示のみにする必要があるため、ゲッターはカプセル化を中断しません。ただし、ライフタイムプロセスの要素にアクセサを追加すると、カプセル化が壊れます。

ほとんどの場合と同様に、カプセル化の定義はリテラルではなく、相対的です。クラス外でXを見ることができますか？Yを変更できますか？このクラスのオブジェクトに適用されるすべてのものですか、それとも複数のクラスに機能が分散していますか？

メソッドの名前を変更するだけではありません。2つの方法は機能が異なります。

（あなたの心の中にこれを描きなさい）

get_cheeseとset_cheeseはチーズを公開します。putCheese（）とtakeCheese（）は、チーズを非表示にして管理し、ユーザーがチーズを処理する方法を提供します。観察者はチーズを見ません。彼/彼女はそれを操作する2つの方法だけを見ます。