Почему C# не предоставляет ключевое слово friend в стиле C++?

Вы можете приблизиться к "другу" C++ с помощью ключевого слова C# "внутренний".

Я подозреваю, что это как-то связано с моделью компиляции C# - построением IL JIT-компиляции во время выполнения. то есть: по той же причине, по которой дженерики C# фундаментально отличаются от дженериков C++.

Вы должны иметь возможность выполнять те же действия, для которых "друг" используется в C++, используя интерфейсы в C#. Это требует, чтобы вы явно определяли, какие члены передаются между двумя классами, что является дополнительной работой, но также может облегчить понимание кода.

Если у кого-то есть пример разумного использования слова «друг», который нельзя смоделировать с помощью интерфейсов, поделитесь им! Я хотел бы лучше понять разницу между C++ и C#.

Наличие друзей в программировании более или менее считается «грязным», и им легко злоупотреблять. Это нарушает отношения между классами и подрывает некоторые фундаментальные атрибуты объектно-ориентированного языка.

При этом это хорошая функция, и я сам много раз использовал ее на C++; и хотел бы использовать его и в C#. Но я уверен, что из-за "чистой" OOness C# (по сравнению с псевдо OOness C++) MS решила, что, поскольку у Java нет ключевого слова друга, C# тоже не должен (шутка;))

Если серьезно: внутреннее не так хорошо, как друг, но оно выполняет свою работу. Помните, что редко вы будете распространять свой код сторонним разработчикам не через DLL; так что до тех пор, пока вы и ваша команда знаете о внутренних классах и их использовании, все будет в порядке.

РЕДАКТИРОВАТЬ Позвольте мне пояснить, как ключевое слово friend подрывает ООП.

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

Если вы работаете с C++ и обнаруживаете себя с помощью ключевого слова friend, это очень сильный признак того, что у вас есть проблема с дизайном, потому что какого черта классу нужен доступ к закрытым членам другого класса ??

Для информации, еще одна связанная, но не совсем такая же вещь в .NET - это [InternalsVisibleTo], который позволяет сборке назначать другую сборку (например, сборку модульного теста), которая (по сути) имеет «внутренний» доступ к типам / членам. в оригинальной сборке.

На самом деле это не проблема C#. Это фундаментальное ограничение в IL. C# ограничен этим, как и любой другой язык .Net, который стремится быть проверяемым. Это ограничение также включает управляемые классы, определенные в C++ / CLI (Раздел спецификаций 20.5).

При этом я думаю, что у Нельсона есть хорошее объяснение того, почему это плохо.

На стороне примечания. Использование друга - это не нарушение инкапсуляции, а, наоборот, обеспечение ее соблюдения. Подобно аксессорам + мутаторам, перегрузке операторов, общедоступному наследованию, понижающему преобразованию, и т.п., он часто используется неправильно, но это не означает, что ключевое слово не имеет или, что еще хуже, плохой цели.

Смотрите сообщениеКонрад Рудольф в другом потоке или, если вы предпочитаете, смотрите соответствующая запись в C++ FAQ.

Friend чрезвычайно полезен при написании модульного теста.

Хотя это происходит за счет небольшого загрязнения объявления вашего класса, это также является напоминанием компилятора о том, какие тесты на самом деле могут заботиться о внутреннем состоянии класса.

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

В C# отсутствует ключевое слово "friend" по той же причине, по которой отсутствует детерминированное уничтожение. Изменение условностей заставляет людей чувствовать себя умными, как будто их новые пути лучше чужих старых. Все дело в гордости.

Сказать, что «классы друзей - это плохо», так же недальновидно, как и другие неквалифицированные утверждения, такие как «не используйте gotos» или «Linux лучше, чем Windows».

Ключевое слово "friend" в сочетании с прокси-классом - отличный способ предоставить только части определенный класса конкретному другому классу (классам). Прокси-класс может выступать в качестве надежного барьера против всех других классов. «public» не допускает такого таргетинга, а использование «protected» для получения эффекта с наследованием неудобно, если действительно нет концептуальных отношений «есть».

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

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

Это для обеспечения соблюдения парадигмы инкапсуляции? так что вам нужно написать методы доступа и что теперь? как вы должны запретить всем (кроме методов класса B) вызывать эти методы? вы не можете, потому что вы тоже не можете контролировать это из-за отсутствия «друга».

Нет идеального языка программирования. C# - один из лучших языков, которые я видел, но глупые оправдания отсутствующих функций никому не помогают. В C++ мне не хватает простой системы событий / делегатов, отражения (+ автоматическая де / сериализация) и foreach, но в C# я скучаю по перегрузке операторов (да, продолжайте говорить мне, что вам это не нужно), параметрам по умолчанию, константе это невозможно обойти, множественное наследование (да, продолжайте говорить мне, что оно вам не нужно, и интерфейсы были достаточной заменой) и возможность принять решение об удалении экземпляра из памяти (нет, это не так уж плохо, если вы не являетесь ремесленник)

С friend разработчик C++ имеет точный контроль над тем, кому доступны закрытые * члены. Но он вынужден разоблачить каждого из частных участников.

С internal разработчик C# имеет точный контроль над набором закрытых членов, которые он раскрывает. Очевидно, он может раскрыть только одного закрытого члена. Но он будет доступен для всех классов в сборке.

Как правило, разработчик желает предоставить только несколько частных методов избранным нескольким другим классам. Например, в шаблоне фабрики классов может быть желательно, чтобы экземпляр класса C1 создавался только фабрикой классов CF1. Следовательно, класс C1 может иметь защищенный конструктор и фабрику дружественных классов CF1.

Как видите, у нас есть 2 измерения, по которым может быть нарушена инкапсуляция. friend пробивает его по одному измерению, internal - по другому. Какой из них является более серьезным нарушением концепции инкапсуляции? Тяжело сказать. Но было бы неплохо иметь в наличии и friend, и internal. Кроме того, хорошим дополнением к этим двум будет третий тип ключевого слова, который будет использоваться по отдельности (например, internal) и указывает целевой класс (например, friend).

* Для краткости я буду использовать «частный» вместо «частный и / или защищенный».

- Ник

Раньше я регулярно использовал friend и не думаю, что это нарушение ООП или признак какой-либо ошибки в дизайне. Есть несколько мест, где это наиболее эффективное средство достижения нужного результата с наименьшим количеством кода.

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

Просто глупо заявлять, что это нарушение ООП для класса протокола / "создателя", чтобы иметь непосредственный доступ ко всем созданным классам - класс-создатель должен был изменять каждый бит данных на пути вверх. Что я считаю наиболее важным, так это свести к минимуму все лишние строки кода BS, к которым обычно приводит модель «ООП ради ООП». Дополнительные спагетти просто порождают больше ошибок.

Знают ли люди, что вы можете применить ключевое слово internal на уровне атрибута, свойства и метода? Это касается не только объявления класса верхнего уровня (хотя большинство примеров, кажется, это демонстрируют).

Если у вас есть класс C++, который использует ключевое слово friend, и вы хотите имитировать это в классе C#: 1. объявить класс C# общедоступным 2. объявить все атрибуты / свойства / методы, которые защищены в C++ и, следовательно, доступны друзьям, как внутренние в C#. 3. создать свойства только для чтения для общего доступа ко всем внутренним атрибутам и свойствам

Я согласен, что это не на 100% то же самое, что и friend, и модульный тест - очень ценный пример необходимости чего-то вроде друга (как и код журналирования анализатора протокола). Однако internal обеспечивает доступ к классам, которые вы хотите получить, а [InternalVisibleTo ()] обрабатывает все остальное - похоже, он был создан специально для модульного тестирования.

Что касается друга «быть лучше, потому что вы можете явно контролировать, какие классы имеют доступ» - что, черт возьми, группа подозрительных злых классов делает в одной и той же сборке в первую очередь? Разбиение сборок на разделы!

Начиная с .Net 3 существует InternalsVisibleToAttribute, но я подозреваю, что они добавили его только для обслуживания тестовых сборок после появления модульного тестирования. Я не вижу многих других причин для его использования.

Он работает на уровне сборки, но выполняет то же самое, что и внутренний; то есть там, где вы хотите распространить сборку, но хотите, чтобы другая нераспределенная сборка имела к ней привилегированный доступ.

Совершенно справедливо они требуют, чтобы сборка друга была сильной, чтобы никто не создал воображаемого друга вместе с вашей защищенной сборкой.

Я прочитал много умных комментариев о ключевом слове «друг», и я согласен, что это полезная вещь, но я думаю, что какое «внутреннее» ключевое слово менее полезно, и оба они все еще плохи для чистого объектно-ориентированного программирования.

Что мы имеем? (говоря о «друге» я также говорю о «внутреннем»)

• использование "друга" делает код менее чистым в отношении oo?

• да;

• не использование "друга" делает код лучше?

• нет, нам все еще нужно установить некоторые частные отношения между классами, и мы сможем это сделать, только если нарушим нашу красивую инкапсуляцию, так что это тоже нехорошо, я могу сказать, что это даже хуже, чем использование «друга».

Использование друга создает некоторые локальные проблемы, а неиспользование его создает проблемы для пользователей библиотеки кода.

общее хорошее решение для языка программирования я вижу так:

// c++ style
class Foo {
  public_for Bar:
    void addBar(Bar *bar) { }
  public:
  private:
  protected:
};

// c#
class Foo {
    public_for Bar void addBar(Bar bar) { }
}

Что вы думаете об этом? Я думаю, что это наиболее распространенное и чисто объектно-ориентированное решение. Вы можете открыть доступ к любому выбранному вами методу для любого класса.

Дружбу можно смоделировать, разделив интерфейсы и реализации. Идея такая: «Требовать конкретный экземпляр, но ограничить доступ для строительства этого экземпляра».

Например

interface IFriend { }

class Friend : IFriend
{
    public static IFriend New() { return new Friend(); }
    private Friend() { }

    private void CallTheBody() 
    {  
        var body = new Body();
        body.ItsMeYourFriend(this);
    }
}

class Body
{ 
    public void ItsMeYourFriend(Friend onlyAccess) { }
}

Несмотря на то, что ItsMeYourFriend() является общедоступным, только класс Friend может получить к нему доступ, поскольку никто другой не может получить конкретный экземпляр класса Friend. У него есть частный конструктор, а фабричный метод New() возвращает интерфейс.

Подробности смотрите в моей статье Друзья и участники внутреннего интерфейса бесплатно с кодированием интерфейсов.

B.s.d.

Было заявлено, что друзья вредит чистому OOness. С чем я согласен.

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

Я думаю, что дружба должна быть добавлена ​​в методологию объектно-ориентированного программирования, но не совсем так, как в C++. Я хотел бы иметь некоторые поля / методы, к которым мой класс друзей может получить доступ, но я НЕ хочу, чтобы они получали доступ ко ВСЕМ моим полям / методам. Как и в реальной жизни, я позволял своим друзьям иметь доступ к моему личному холодильнику, но не позволял им получать доступ к моему банковскому счету.

Это можно реализовать следующим образом

    class C1
    {
        private void MyMethod(double x, int i)
        {
            // some code
        }
        // the friend class would be able to call myMethod
        public void MyMethod(FriendClass F, double x, int i)
        {
            this.MyMethod(x, i);
        }
        //my friend class wouldn't have access to this method 
        private void MyVeryPrivateMethod(string s)
        {
            // some code
        }
    }
    class FriendClass
    {
        public void SomeMethod()
        {
            C1 c = new C1();
            c.MyMethod(this, 5.5, 3);
        }
    }

Это, конечно, вызовет предупреждение компилятора и повредит intellisense. Но он сделает свою работу.

Кстати, я думаю, что уверенный в себе программист должен выполнять модуль тестирования, не обращаясь к закрытым членам. это выходит за рамки возможностей, но попробуйте почитать про TDD. однако, если вы все еще хотите это сделать (имея друзей на C++), попробуйте что-нибудь вроде

#if UNIT_TESTING
        public
#else
        private
#endif
            double x;

поэтому вы пишете весь свой код без определения UNIT_TESTING, и когда вы хотите выполнить модульное тестирование, вы добавляете #define UNIT_TESTING в первую строку файла (и пишете весь код, который выполняет модульное тестирование, под #if UNIT_TESTING). С этим нужно обращаться осторожно.

Поскольку я считаю, что модульное тестирование - плохой пример для использования друзьями, я бы привел пример, почему я считаю, что друзья могут быть хорошими. Предположим, у вас есть система (класс) взлома. По мере использования тормозная система изнашивается и требует ремонта. Теперь вы хотите, чтобы это исправил только лицензированный механик. Чтобы сделать пример менее тривиальным, я бы сказал, что механик будет использовать свою личную (частную) отвертку, чтобы исправить это. Вот почему класс механики должен дружить с классом breakSystem.

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

У меня есть страница ASP.NET, которая наследует мою собственную базовую страницу, которая, в свою очередь, наследует System.Web.UI.Page. На этой странице у меня есть код, который обрабатывает отчеты об ошибках конечного пользователя для приложения в защищенном методе.

ReportError("Uh Oh!");

Теперь у меня есть пользовательский элемент управления, который содержится на странице. Я хочу, чтобы пользовательский элемент управления мог вызывать методы сообщения об ошибках на странице.

MyBasePage bp = Page as MyBasePage;
bp.ReportError("Uh Oh");

Этого не может быть, если метод ReportError защищен. Я могу сделать его внутренним, но он доступен для любого кода сборки. Я просто хочу, чтобы он был доступен для элементов пользовательского интерфейса, которые являются частью текущей страницы (включая дочерние элементы управления). В частности, я хочу, чтобы мой базовый класс управления определял точно такие же методы сообщения об ошибках и просто вызывал методы на базовой странице.

protected void ReportError(string str) {
    MyBasePage bp = Page as MyBasePage;
    bp.ReportError(str);
}

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

[Friend(B)]
class A {

    AMethod() { }

    [Friend(C)]
    ACMethod() { }
}

class B {
    BMethod() { A.AMethod() }
}

class C {
    CMethod() { A.ACMethod() }
}

В случае с моим предыдущим примером, возможно, есть что-то вроде следующего (можно поспорить с семантикой, но я просто пытаюсь донести идею):

class BasePage {

    [Friend(BaseControl.ReportError(string)]
    protected void ReportError(string str) { }
}

class BaseControl {
    protected void ReportError(string str) {
        MyBasePage bp = Page as MyBasePage;
        bp.ReportError(str);
    }
}

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

Дружбу также можно смоделировать с помощью «агентов» - некоторых внутренних классов. Рассмотрим следующий пример:

public class A // Class that contains private members
{
  private class Accessor : B.BAgent // Implement accessor part of agent.
  {
    private A instance; // A instance for access to non-static members.
    static Accessor() 
    { // Init static accessors.
      B.BAgent.ABuilder = Builder;
      B.BAgent.PrivateStaticAccessor = StaticAccessor;
    }
    // Init non-static accessors.
    internal override void PrivateMethodAccessor() { instance.SomePrivateMethod(); }
    // Agent constructor for non-static members.
    internal Accessor(A instance) { this.instance = instance; }
    private static A Builder() { return new A(); }
    private static void StaticAccessor() { A.PrivateStatic(); }
  }
  public A(B friend) { B.Friendship(new A.Accessor(this)); }
  private A() { } // Private constructor that should be accessed only from B.
  private void SomePrivateMethod() { } // Private method that should be accessible from B.
  private static void PrivateStatic() { } // ... and static private method.
}
public class B
{
  // Agent for accessing A.
  internal abstract class BAgent
  {
    internal static Func<A> ABuilder; // Static members should be accessed only by delegates.
    internal static Action PrivateStaticAccessor;
    internal abstract void PrivateMethodAccessor(); // Non-static members may be accessed by delegates or by overrideable members.
  }
  internal static void Friendship(BAgent agent)
  {
    var a = BAgent.ABuilder(); // Access private constructor.
    BAgent.PrivateStaticAccessor(); // Access private static method.
    agent.PrivateMethodAccessor(); // Access private non-static member.
  }
}

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

Отвечу только на вопрос "Как".

Здесь так много ответов, однако я хотел бы предложить своего рода «шаблон проектирования» для достижения этой функции. Я буду использовать простой языковой механизм, который включает:

• Интерфейсы
• Вложенный класс

Например, у нас есть 2 основных класса: Студент и Университет. У студента есть средний балл, доступ к которому имеет только университет. Вот код:

public interface IStudentFriend
{
    Student Stu { get; set; }
    double GetGPS();
}

public class Student
{
    // this is private member that I expose to friend only
    double GPS { get; set; }
    public string Name { get; set; }

    PrivateData privateData;

    public Student(string name, double gps) => (GPS, Name, privateData) = (gps, name, new PrivateData(this);

    // No one can instantiate this class, but Student
    // Calling it is possible via the IStudentFriend interface
    class PrivateData : IStudentFriend
    {
        public Student Stu { get; set; }

        public PrivateData(Student stu) => Stu = stu;
        public double GetGPS() => Stu.GPS;
    }

    // This is how I "mark" who is Students "friend"
    public void RegisterFriend(University friend) => friend.Register(privateData);
}

public class University
{
    var studentsFriends = new List<IStudentFriend>();

    public void Register(IStudentFriend friendMethod) => studentsFriends.Add(friendMethod);

    public void PrintAllStudentsGPS()
    {
        foreach (var stu in studentsFriends)
            Console.WriteLine($"{stu.Stu.Name}: stu.GetGPS()");
    }
}

public static void Main(string[] args)
{
    var Technion = new University();
    var Alex     = new Student("Alex", 98);
    var Jo       = new Student("Jo", 91);

    Alex.RegisterFriend(Technion);
    Jo.RegisterFriend(Technion);
    Technion.PrintAllStudentsGPS();

    Console.ReadLine();
}

Фактически, C# дает возможность получить такое же поведение в чистом виде ООП без специальных слов - это частные интерфейсы.

Поскольку вопрос Что представляет собой эквивалент слова friend в C#? был помечен как дублирующий к этой статье, и там никто не предлагает действительно хорошей реализации - я покажу здесь ответы на оба вопроса.

Основная идея была взята отсюда: Что такое приватный интерфейс?

Скажем, нам нужен какой-то класс, который мог бы управлять экземплярами других классов и вызывать для них какие-то специальные методы. Мы не хотим давать возможность вызывать эти методы другим классам. Это в точности то же самое, что ключевое слово друга C++ делает в мире C++.

Я думаю, что хорошим примером на практике может быть шаблон Full State Machine, когда какой-либо контроллер обновляет объект текущего состояния и при необходимости переключается на другой объект состояния.

Ты мог бы:

• Самый простой и худший способ сделать метод Update () общедоступным - надеюсь все понимают, почему это плохо.
• Следующий способ - пометить его как внутренний. Достаточно хорошо, если вы положите классы в другую сборку, но даже тогда каждый класс в этой сборке мог вызвать каждый внутренний метод.
• Используйте частный / защищенный интерфейс - и я пошел по этому пути.

Controller.cs

public class Controller
{
    private interface IState
    {
        void Update();
    }

    public class StateBase : IState
    {
        void IState.Update() {  }
    }

    public Controller()
    {
        //it's only way call Update is to cast obj to IState
        IState obj = new StateBase();
        obj.Update();
    }
}

Program.cs

class Program
{
    static void Main(string[] args)
    {
        //it's impossible to write Controller.IState p = new Controller.StateBase();
        //Controller.IState is hidden
        var p = new Controller.StateBase();
        //p.Update(); //is not accessible
    }
}

Ну что насчет наследования?

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

Controller.cs

public class Controller
{
    protected interface IState
    {
        void Update();
    }

    public class StateBase : IState
    {
        void IState.Update() { OnUpdate(); }
        protected virtual void OnUpdate()
        {
            Console.WriteLine("StateBase.OnUpdate()");
        }
    }

    public Controller()
    {
        IState obj = new PlayerIdleState();
        obj.Update();
    }
}

PlayerIdleState.cs

public class PlayerIdleState: Controller.StateBase
{
    protected override void OnUpdate()
    {
        base.OnUpdate();
        Console.WriteLine("PlayerIdleState.OnUpdate()");
    }
}

И, наконец, пример того, как проверить наследование броска контроллера класса: ControllerTest.cs

class ControllerTest: Controller
{
    public ControllerTest()
    {
        IState testObj = new PlayerIdleState();
        testObj.Update();
    }
}

Надеюсь, я рассмотрю все случаи и мой ответ был полезен.