Где модификатор доступа Friend предназначен для использования?

Question

Единственное место, где я видел использованный модификатор Friend, находится в конструкторе WinForms, как указано в Почему в Winforms установлен модификатор Friend? и VB.NET: что делаетмодификатор 'friend' делает? .

Модификатор Friend - это почти произвольно широкий уровень доступа, который был создан для решения какой-то исторической архитектурной проблемы в VB. Интересно, есть ли у кого-нибудь значимое продолжение?использовать для этого?

У меня были некоторые желания открывать методы только для заданного пространства имен, чтобы объединить функциональные возможности связанной коллекции объектов и управлять любыми их не поточно-безопасными методами, одновременно подвергаябезопасные общедоступные методы в более широкой области применения в одной сборке.Этот уровень доступа еще не существует.Тогда, возможно, является следствием того, что мое использование сборок и пространств имен расходится с тем, что предполагается?

Во многих случаях невозможно разделить функциональность на разные сборки из-за строгой иерархии, которая имеет сборки, что приводитиметь группы связанных, но отдельных объектов, которые имеют доступ к небезопасным методам друг друга.

Редактировать: Хотя я знаю функцию модификатора, мне любопытно, какие практические цели имеют людипотому что я не сталкивался с ситуацией, когда это было бы правильным решением.

Answer 1

Я использую его в классах для предотвращения использования функций, методов или свойств вне моей сборки.

Внутри сборки Friend и Public делают одно и то же, следовательно, это дружественно для разработчика. Но если класс используется из внешней сборки, все, что отмечено Friend, будет недоступно, тогда как Public будет.

Эквивалент C # равен internal. Имя internal, вероятно, дает лучшее определение, чем Friend его предполагаемого использования.

Вот произвольный пример. У меня есть DLL, которая содержит кучу пользовательских элементов управления, которые все должны рисовать определенные изображения:

Friend Class ControlDraw

  Public Shared Sub DrawArrow(ByVal g As Graphics, ByVal r as Rectangle, _
                              ByVal ad As ArrowDirection, ByVal ac As Color)

    //' Draw Special Arrow:

  End Sub

End Class

Я могу использовать этот код во всех элементах управления в моем проекте. Но когда я публикую библиотеку DLL и позволю другим использовать ее, функция DrawArrow недоступна для конечного пользователя, только элементы управления внутри проекта.

Зачем это делать?

Если бы это было Public, то я бы никогда не смог изменить параметры, потенциально не нарушив каких-либо потребителей функции. Но так как это мой собственный метод, я могу добавить другой параметр для BackColor или чего-либо еще и обновить все свои элементы управления, которые его используют, из моего собственного проекта.

Я в основном говорю, что класс или функция Friend должны беспокоить меня, а не конечного пользователя. Как только вы делаете что-то Public для внешнего мира, вы теряете немного контроля над этим.

Также нашел это из ответа Эрика Липперта об использовании Internal:

Дело не в том, что это осложняет жизнь Бобу. Это то, что он позволяет вам контролировать, какие дорогостоящие обещания дает проект А. в отношении функций, срока службы, совместимости и т. Д.

Answer 2

То, что у вас есть, это не языковая проблема, а догма ООП в целом.

Модификатор Friend может сбивать с толку, потому что он не ведет себя так, как в старых языках, таких как C ++.Причина, по которой он не ведет себя одинаково, заключается в том, что он не тот же.

Модификатор Friend предоставляет доступ к объявленному объекту в области сборки, что означает, что любой класс всборка может получить доступ к этому объекту, но она все равно не будет использоваться для кода, потребляющего вашу сборку.Если это поможет взглянуть также на C # Внутренний модификатор .

Что касается того, почему ООП идет вразрез с C ++, то модификатор Friend выходит за рамки моих знаний, но, возможно, этот другой вопрос SO может помочь.