回答。

Visual Basicの"protected"（Protected）アクセスレベルは、カプセル化のために設計されています。これは、クラスのメンバーがそのクラス自身とその派生クラスからのみアクセス可能であることを意味します。これは、OOPアーキテクチャを組織するためだけでなく、オブジェクトの内部実装への直接アクセスを制限するためにも重要です。

歴史的に、クラシックVB6ではこのような柔軟性はほとんどなく、VB.NETからは現代のOOPスタンダードに対応する完全なアクセス修飾子が追加されました。

問題

アクセスを不適切に構成すると、クラスのプロパティやメソッドが誤って使用され、潜在的にカプセル化が破られる可能性があります。たとえば、公開メソッド（Public）はすべての人にアクセス可能で、外部コンポーネントを含むのに対し、protectedは派生クラスへのアクセスを制限します。

解決策

VB.NETでは、Protected、Protected Friend、Private修飾子が使用できます。Protectedはクラスとその派生クラス内でのみ見え、Protected Friendはアセンブリ内とその派生クラス内で見え、Privateは宣言されたクラス内でのみ見えます。

コードの例:

Public Class Animal
    Protected Sub Eat()
        Console.WriteLine("Eating...")
    End Sub
    Private Sub Sleep()
        Console.WriteLine("Sleeping...")
    End Sub
End Class

Public Class Dog
    Inherits Animal
    Public Sub PerformEat()
        Eat() ' アクセス可能: Protected
    End Sub
    ' Sleep()はアクセス不可: Private
End Class

重要な特徴:

Protected修飾子は、クラスのメンバーへのアクセスをそのクラス自身とその派生クラスに制限します
Protected Friendは、スコープをアセンブリ全体とその派生クラスに拡張します
Privateは、クラス内で要素を完全に閉じます

問題を引き起こす質問。

Protected修飾子は、アセンブリ内のすべてのクラスにクラスメンバーの可視性を提供できますか？

いいえ、クラス自身とその派生クラスのみに対してです。Protected Friendは、そのクラス、その派生とアセンブリ内のすべてのクラスのためのものです。

アセンブリ外の子クラスにのみ見えるプロパティを明示的に指定することはできますか？

いいえ、そのようなレベルはありません。Protected Friendは、同時に派生クラスとアセンブリの間の可視性を分けますが、これらの領域を分けることはできません。

基底クラスでメソッドがProtectedとして定義されている場合、子クラスでそれをPublicとしてオーバーライドできますか？

いいえ、アクセスレベルは厳密に下方に維持または拡張することしかできず、狭めることはできません。アクセスを拡大することはカプセル化の原則に反します。 .NETコンパイラは、アクセスを狭めようとした場合にエラーを出力します。

一般的なエラーとアンチパターン

外部からアクセスされるべきでないメソッド/フィールドにPublicを使用すること
Protectedの代わりにProtected Friendを誤用し、機密のロジックを外にエクスポートしてしまうこと
アクセス修飾子を全く使用しないこと（デフォルトで要素はPublic）

実生活の例

ネガティブケース

初心者の開発者は、ビジネスロジックの内部メソッドをPublicとして宣言しました。その後、プログラムを更新する際に、外部コンポーネントからのコントロールされていないアクセスにより多くのバグが発生しました。

利点:

実装の簡単さ — アクセスを考慮する必要がない

欠点:

セキュリティとカプセル化が破られている
リファクタリングや更新時にロジックが壊れる

ポジティブケース

経験豊富なプログラマーは、ProtectedとPrivateを使用し、親クラスと子クラス間で責任の範囲を明確に分けます。このため、更新が外部APIに影響を与えず、バグの数が減少しました。