タグ付けされた質問 「access-modifiers」

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

7
プライベート静的メソッドがあるのはなぜですか?
質問を解決したかっただけです。プライベートな可視性を持つ通常のメソッドとは対照的に、プライベートな静的メソッドを持つことのポイントは何ですか? 静的メソッドを持つことの利点は、クラスのインスタンスなしで呼び出すことができることだと思っていましたが、そのプライベートは静的であるというポイントさえありますか? 私が考えることができる唯一の理由は、オブジェクトレベルではなく、クラスレベルでメソッドを概念的に理解するのに役立つということです。

3
Pythonに明示的なアクセス修飾子がないのはなぜですか:
「明示的が暗黙的よりも優れている」場合、Pythonには明示的アクセス修飾子がないのはなぜですか:Public、Protected、Privateなど? プログラマーはヒントを通して何をすべきかを知っておくべきだという考えを知っています-「ブルートフォース」を使用する必要はありません。しかし、IMOの「カプセル化」または「情報隠蔽」は単に人を締め出すためだけではなく、組織と構造の問題です。物理層システムのように、開発レイヤーは明確に区切られたスコープと境界を自己定義する必要があります。 Pythonでアクセス制限が明示されているのではなく、それ以外の場合は完璧に近いと思われる言語について、なぜアクセス制限が暗黙的に含まれているのかについて、誰かがここで助けてくれますか? 編集:これまでに3つの提案された答えを見てきましたが、私の質問には2つの部分があることに気付きました。 たとえば、キーワードがないのはなぜですか private def myFunc(): dostuff.... IMOの代わりに、typeいアンダースコアを入力します。しかし、それは重要なポイントではありません。 さらに重要なことには: これらのアクセス修飾子が「推奨事項」またはヒントのみであり、強制されないのはなぜですか。後で変更するのは難しいでしょうか?「保護された」を「パブリック」に変更するのは非常に簡単です-複雑な継承チェーンがあり、それが難しくなると、デザインが貧弱になります-書きやすい言語機能に依存するのではなく、デザインを洗練する必要があります不十分な構造のコード。 アクセス修飾子が適用されると、コードは自動的に区分化されます。特定のセグメントが範囲外であることを知っているので、必要な場合と必要な場合を除き、それらを処理する必要はありません。そして、あなたのデザインが良くなく、物事をさまざまな範囲に出し入れしていることに気付いた場合、言語はあなたの行為をきれいにするのに役立ちます。 Pythonが大好きなのと同じように、この2番目の点は深刻な欠陥であると感じています。そして、これに対する良い答えをまだ見ていません。

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

5
コンストラクターでセッターを使用することが一般的なパターンにならなかったのはなぜですか?
アクセサーと修飾子(セッターとゲッター)は、次の3つの主な理由で便利です。 これらは変数へのアクセスを制限します。 たとえば、変数にアクセスすることはできますが、変更することはできません。 パラメータを検証します。 彼らはいくつかの副作用を引き起こす可能性があります。 大学、オンラインコース、チュートリアル、ブログ記事、およびWeb上のコード例はすべて、アクセサと修飾子の重要性について強調しています。最近のコードには「必須」のように感じられます。したがって、以下のコードのように追加の値を提供しなくても、それらを見つけることができます。 public class Cat { private int age; public int getAge() { return this.age; } public void setAge(int age) { this.age = age; } } そうは言っても、実際にパラメーターを検証し、無効な入力が提供された場合に例外をスローしたりブール値を返したりする、より有用な修飾子を見つけることは非常に一般的です: /** * Sets the age for the current cat * @param age an integer with the valid values between …

7
Javaで、保護されたメンバーが同じパッケージのクラスにアクセスできるようになったのはなぜですか?
公式文書から... モディファイヤクラスパッケージサブクラスワールド パブリックYYYY 保護されたYYYN 修飾子なしYYNN プライベートYNNN 問題は、同じパッケージ内のクラスから保護されたメンバーにアクセスする必要があるユースケースを覚えていないことです。 この実装の背後にある理由は何ですか? 編集:明確にするために、同じパッケージ内のサブクラスとクラスの両方が保護されたフィールドまたはメソッドにアクセスする必要がある特定のユースケースを探しています。 package some.package; public class A { protected void protectedMethod(){ // do something } } package another.package; public class B extends A{ public void someMethod(){ // accessible because B is a subclass of A protectedMethod(); } } package some.package; public class C …

6
保護されたメソッドの実際のシナリオ
今日、私は基本的protectedにC ++コードでメソッドを使用しないことに気付きました。親の非パブリックメソッドを呼び出す必要性をほとんど感じないからです。テンプレートメソッドパターンではJavaでprotectedを使用していますが、C ++でプライベートメソッドをオーバーライドできるため、ここでも必要protectedありません。 それではprotected、C ++コードでメソッドを使用する実際のシナリオは何ですか? (私は一般的に実装の継承があまり好きではないことに注意してください、それは多くを説明するかもしれません...)

3
デフォルトのアクセス修飾子を使用する必要があるか—コーディング慣行?
通常、新しいグローバル変数を作成するときは、そのアクセス修飾子を定義しません。したがって、Javaのように、プロパティのデフォルトアクセス修飾子を採用します。デフォルトのスコープ外でその変数にアクセスする必要がある場合は、アクセス修飾子を変更します。それ以外の場合はそのままにしておきます。だから私の質問は「私はそれを正しくやっていますか?デフォルトのアクセス変数を持っているのは普通ですか?またはそれらにプライベート/パブリックを使用するべきですか?アクセス修飾子を使用しないのは良いコーディング慣行ですか?」
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.