Ответ.

В Visual Basic уровень доступа "protected" (Protected) предназначен для инкапсуляции — он позволяет членам класса быть доступными только в самом классе и его производных. Это важно как для организации ООП архитектуры, так и для ограничения прямого доступа к внутренней реализации объекта.

Исторически в классическом VB6 подобной гибкости почти не было, а начиная с VB.NET были добавлены полноценные модификаторы доступа, соответствующие современным стандартам ООП.

Проблема

Ошибка при организации доступа может привести к неправильному использованию свойств или методов класса и, потенциально, к нарушению инкапсуляции. Например, открытый метод (Public) будет доступен всем, включая внешние компоненты, тогда как защищённый ограничивает доступ производными.

Решение

В VB.NET доступны модификаторы Protected, Protected Friend и Private. Protected виден только внутри класса и его наследников, Protected Friend — внутри сборки (assembly) и наследников, 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 Friend вместо Protected и случайный экспорт чувствительной логики наружу
Неиспользование модификаторов доступа вовсе (по умолчанию элементы Public)

Пример из жизни

Негативный кейс

Начинающий разработчик объявил внутренние методы бизнес-логики как Public. Через некоторое время при обновлении программы появилось множество багов из-за неконтролируемого доступа к этим методам сторонними компонентами.

Плюсы:

Простота реализации — не требуется думать о доступе

Минусы:

Нарушается безопасность и инкапсуляция
Ломается логика при рефакторинге или обновлении

Позитивный кейс

Опытный программист использует Protected и Private, разделяет зоны ответственности между родительскими и дочерними классами. Благодаря этому обновления не влияют на внешние API, уменьшено число багов.