タグ付けされた質問 「encapsulation」

privateクラスのフィールド/プロパティ/属性の可視性は有用ですか？OOPでは、遅かれ早かれ、クラスのサブクラスを作成することになります。その場合は、実装を完全に修正し、理解できると便利です。 クラスをサブクラス化するときに最初に行うことの1つは、多数のprivateメソッドをに変更することprotectedです。ただし、外界から詳細を隠すことは重要です。そのため、必要なのprotectedは単なるではなく、ですpublic。 私の質問は：privateではなくprotected、優れたツールである重要なユースケースについて知っていますか、または2つのオプション " protected＆public"でOOP言語に十分でしょうか？

265 object-oriented  encapsulation  access-modifiers 

クラスにプライベート変数が必要なのはなぜですか？ 私が読んだプログラミングに関するすべての本は、これはプライベート変数であると述べています。 これらの説明の言葉遣いは、私たちが本当に自分の職業に信頼の危機を抱えているように思えました。他のプログラマがコードを台無しにしようとしているように、説明は常に聞こえました。しかし、プライベート変数を持たない多くのプログラミング言語があります。 プライベート変数は何を防ぎますか？ 特定のプロパティをプライベートにするかどうかをどのように決定しますか？デフォルトですべてのフィールドがプライベートである必要がある場合、クラスにパブリックデータメンバーがあるのはなぜですか？ どのような状況で変数を公開する必要がありますか？

210 object-oriented  encapsulation 

私が理解している限り、ほとんどの人は、プライベートメソッドを直接テストするのではなく、パブリックメソッドを呼び出してテストする必要があることに同意しているようです。私は彼らの要点を見ることができますが、「TDDの3つの法則」に従い、「赤-緑-リファクタリング」サイクルを使用しようとすると、いくつかの問題があります。例で説明するのが一番だと思います。 現在、ファイル（タブ区切りデータを含む）を読み取り、非数値データを含むすべての列をフィルターで除外できるプログラムが必要です。おそらくこれを行うためのシンプルなツールが既にいくつか用意されていると思いますが、TDDの練習をするのにすてきできれいなプロジェクトになりそうだと思ったため、最初から実装することにしました。 したがって、最初に、「赤い帽子をかぶる」、つまり、失敗するテストが必要です。私は、行内のすべての非数値フィールドを見つけるメソッドが必要だと考えました。だから、私は簡単なテストを書いて、もちろんすぐにコンパイルに失敗するので、関数自体の記述を開始し、2、3サイクル（赤/緑）前後に作業関数と完全なテストができました。 次に、ファイルを1行ずつ読み取り、最終的に削除する必要があるすべての列を収集するために各行で「findNonNumericFields」関数を呼び出す関数「gatherNonNumericColumns」を続行します。いくつかの赤と緑のサイクルがあり、作業機能と完全なテストが完了しました。 今、私はリファクタリングする必要があると考えています。私のメソッド「findNonNumericFields」は、「gatherNonNumericColumns」を実装するときに必要だと考えたために設計されたため、「findNonNumericFields」をプライベートにするのが合理的だと思われます。ただし、テストしていたメソッドにアクセスできなくなるため、最初のテストが中断されます。 だから、私はプライベートメソッドと、それをテストするテストスイートになります。多くの人がプライベートメソッドをテストすべきでないとアドバイスしているので、私はここで一角に自分を描いたように感じます。しかし、どこで正確に失敗しましたか？ より高いレベルで始めて、最終的には私のパブリックメソッド（つまり、findAndFilterOutAllNonNumericalColumns）となるものをテストするテストを作成することもできましたが、それはTDDの全ポイントに少なくとも反すると感じます（少なくともボブおじさんによれば） ：テストと本番コードの作成を絶えず切り替える必要があります。また、任意の時点で、すべてのテストが最後の1分以内に機能しました。パブリックメソッドのテストを書くことから始めた場合、プライベートメソッドのすべての詳細が機能するようになるまでに数分（または数時間、あるいは非常に複雑な場合は数日）があり、テストがパブリックをテストするためメソッドが渡されます。 じゃあ何をすればいいの？TDD（急速な赤緑リファクタリングサイクル）は、単にプライベートメソッドと互換性がありませんか？または、私の設計に欠陥がありますか？

91 tdd  refactoring  encapsulation 

私が携わっているほとんどのプロジェクトは、いくつかのオープンソースコンポーネントを使用しています。一般的な原則として、コードのすべてのコンポーネントをサードパーティのライブラリにバインドするのを常に避け、代わりにカプセル化ラッパーを経由して変更の痛みを避けるのは良い考えですか？ 例として、ほとんどのPHPプロジェクトはlog4phpをロギングフレームワークとして直接使用します。つまり、\ Logger :: getLogger（）を介してインスタンス化し、-> info（）または-> warn（）メソッドなどを使用します。ただし、何らかの点で優れた仮想ロギングフレームワークが表示される場合があります。現状では、log4phpメソッドシグネチャに密接に関連するすべてのプロジェクトは、新しいシグネチャに適合するために、数十箇所で変更する必要があります。これは明らかにコードベースに大きな影響を与え、変更は潜在的な問題です。 この種のシナリオから将来の新しいコードベースを保証するために、ロギング機能をカプセル化し、最小限の変更で将来のロギングの動作方法を変更するために、ロギング機能をカプセル化し、簡単にできるようにするラッパークラスをしばしば検討します（そして時々実装します） ; コードがラッパーを呼び出すと、ラッパーは呼び出しをロギングフレームワークdu jourに渡します。 他のライブラリにはもっと複雑な例があることを念頭に置いて、私は過剰に設計しているのですか、それともほとんどの場合賢明な予防策ですか？ 編集：その他の考慮事項-依存性注入とテストダブルを使用するには、とにかくほとんどのAPIを抽象化する必要があります（「コードの実行を確認し、その状態を更新しますが、ログコメントの書き込み/実際のデータベースへのアクセスはしません」）。これは決定者ではありませんか？

78 third-party-libraries  encapsulation 

典型的な（適切に設計された）MVC Webアプリでは、データベースはモデルコードを認識せず、モデルコードはコントローラーコードを認識せず、コントローラーコードはビューコードを認識しません。（ハードウェアと同じくらい、あるいはそれ以上のレベルで開始することもでき、パターンも同じになると思います。） 別の方向に進むと、1つ下のレイヤーに移動できます。ビューはコントローラーを認識できますが、モデルは認識できません。コントローラーはモデルを認識できますが、データベースは認識できません。モデルはデータベースを認識できますが、OSは認識できません。（より深いものはおそらく無関係です。） なぜこれが良いアイデアなのか直感的に把握できますが、明確に説明することはできません。なぜこの単方向スタイルのレイヤー化が良いアイデアなのでしょうか？

66 architecture  mvc  encapsulation  layers 

私は、ゲッターとセッターのメソッドとカプセル化に関する興味深いインターネットの議論に入りました。誰かがすべきことは、それらを「純粋」に保ち、カプセル化を確保するための割り当て（セッター）または変数アクセス（ゲッター）だけだと言いました。 これは、最初にゲッターとセッターを持つという目的を完全に無効にし、検証と他のロジック（もちろん、奇妙な副作用なし）を許可する必要があると思いますか？ 検証はいつ行われますか？ セッター内で値を設定するとき（オブジェクトが無効な状態になるのを防ぐため-私の意見） 値を設定する前、セッターの外側 オブジェクト内で、値が使用されるたびに セッターは値の変更を許可されていますか（有効な値を標準的な内部表現に変換する可能性があります）？

45 object-oriented  language-agnostic  encapsulation 

ここでいくつかのコードを読んでいて、enumがhtmlタグの名前を保存するために使用されているのを見ました。なぜこれを行う必要があるのでしょうか？この戦略を使用するとどのようなメリットがありますか？ コンパイルされた言語または静的に型付けされた言語で列挙型がどのように役立つかは知っていますが、動的に型付けされた言語で列挙型を見ると、上記のコード例のように興味があります。それで、質問は基本的に、動的に型付けされた言語で列挙型が必要なのか、それともまったく必要なのか、ということです。

32 javascript  programming-practices  encapsulation  enum 

これらの2つのケースの間で一般的に受け入れられている方法は次のとおりです。 function insertIntoDatabase(Account account, Otherthing thing) { database.insertMethod(account.getId(), thing.getId(), thing.getSomeValue()); } または function insertIntoDatabase(long accountId, long thingId, double someValue) { database.insertMethod(accountId, thingId, someValue); } 言い換えれば、一般的にオブジェクト全体を渡すか、必要なフィールドだけを渡す方が良いでしょうか？

31 design-patterns  object-oriented  programming-practices  coding-standards  encapsulation 

具体的には、JavaScriptで記述しています。 私の主な機能が機能Aであるとしましょう。機能Aが機能Bを複数回呼び出し、機能Bが他のどこでも使用されていない場合、機能A内に機能Bを配置するだけですか？ それは良い習慣ですか？または、関数Bを関数Aと同じスコープに配置する必要がありますか？

30 javascript  programming-practices  patterns-and-practices  encapsulation  scope 

私がこの質問をしているのは、彼らが非常に正当な理由でそれをし、ほとんどの人がそれを適切に使用していないと信じているからです。しかし、私の理論が本当なら、なぜプライベートアクセス修飾子が含まれているのか分かりません...？ デフォルトのアクセスが適切に使用されると、カプセル化を維持しながら、テスト容易性が向上すると考えています。また、プライベートアクセス修飾子を冗長にします。 デフォルトのアクセス修飾子は、他の世界から隠される必要があるメソッドに固有のパッケージを使用することで同じ効果を提供するために使用できます。テストフォルダー内のパッケージは、ソースフォルダーで宣言されているすべてのデフォルトメソッドにアクセスできます。 これが、Javaがパッケージアクセスを「デフォルト」として使用する理由だと思います。しかし、なぜプライベートアクセスも含まれているのか分かりません、有効なユースケースがあると確信しています...

26 java  unit-testing  encapsulation  access-modifiers  language-specifications 

私が出会ったOOP原則の1つは次のとおりです。-さまざまなものをカプセル化します。 私はフレーズの文字通りの意味が何であるかを理解しています。しかし、私はそれがより良いデザインにどの程度貢献するのかわかりません。誰かが良い例を使って説明できますか？

25 design  design-patterns  object-oriented  encapsulation 

私の質問はSystem.inとSystem.outクラスに関連しています（標準ライブラリにあるようなものがあるかもしれません）。何故ですか？それはOOPの悪い習慣ではありませんか？次のように使用しないでください：System.getIn()およびSystem.getOut()？私はいつもこの質問をしてきました。ここで良い答えが見つかることを望みます。

25 java  object-oriented  encapsulation 

同じオブジェクトインスタンスのプライベートメソッドでパブリックメソッドを呼び出すのはコードの匂いですか？

25 object-oriented  language-agnostic  encapsulation 

プライベートな変数を持つクラスがあり、クラスにはその変数のゲッターとセッターがあります。なぜその変数を公開しないのですか？ ゲッターとセッターを使用する必要があると思うのは、setまたはget以外の操作を行う必要がある場合だけです。例： void my_class::set_variable(int x){ /* Some operation like updating a log */ this->variable = x; }

23 c++  encapsulation  setters 

カプセル化とは何か、それを実装する3つの手法であるアソシエーション、アグリゲーション、コンポジションについて多くの理論を経験しました。 私が見つけたのは： カプセル化 カプセル化は、クラス内のフィールドをプライベートにし、パブリックメソッドを介してフィールドへのアクセスを提供する技術です。フィールドがプライベートとして宣言されている場合、クラス外の誰もアクセスできないため、クラス内のフィールドは非表示になります。このため、カプセル化はデータ隠蔽とも呼ばれます。 カプセル化は、クラス外で定義された他のコードがコードとデータにランダムにアクセスすることを防ぐ保護バリアとして説明できます。データとコードへのアクセスは、インターフェイスによって厳密に制御されます。 カプセル化の主な利点は、コードを使用する他の人のコードを壊すことなく、実装されたコードを変更できることです。この機能により、カプセル化により、コードの保守性、柔軟性、および拡張性が向上します。 協会 関連付けは、すべてのオブジェクトに独自のライフサイクルがあり、所有者がいない関係です。教師と生徒の例を見てみましょう。複数の生徒が1人の教師に関連付けられ、1人の生徒が複数の教師に関連付けられますが、オブジェクト間に所有権はなく、両方に独自のライフサイクルがあります。どちらも独立して作成および削除できます。 集計 集約は、すべてのオブジェクトに独自のライフサイクルがある特殊な形式の関連付けですが、所有権があり、子オブジェクトは別の親オブジェクトに属することはできません。学科と教師の例を見てみましょう。1人の教師を複数の部門に所属させることはできませんが、部門を削除しても教師オブジェクトは破棄されません。それは「has-a」関係と考えることができます。 組成 合成は再び集約の特殊な形式であり、これを「死」関係と呼ぶことができます。これは強力なタイプの集約です。子オブジェクトにはライフサイクルがありません。親オブジェクトを削除すると、すべての子オブジェクトも削除されます。もう一度、家と部屋の関係の例を見てみましょう。家には複数の部屋を含めることができますが、部屋の独立した生活はなく、2つの異なる家に属することはできません。家を削除すると、部屋は自動的に削除されます。 質問は： 今、これらはすべて実世界の例です。実際のクラスコードでこれらの手法を使用する方法についての説明を探しています。私が意味する、カプセル化のための3つの異なる技術を使用するためのポイントは何か、これらの技術を実装する方法とどのように一度に適用される技術を選択します。

20 object-oriented  encapsulation