Dlaczego C # nie zapewnia słowa kluczowego „przyjaciel” w stylu C ++? [Zamknięte]

W C ++ przyjaciel słów kluczowych pozwala class Awyznaczyć class Bjako przyjaciela. Umożliwia Class Bto dostęp do private/ protectedczłonków class A.

Nigdy nie czytałem niczego, dlaczego zostało to pominięte w C # (i VB.NET). Większość odpowiedzi na to wcześniejsze pytanie StackOverflow wydaje się mówić, że jest to użyteczna część C ++ i istnieją dobre powody, aby z niej korzystać. Z mojego doświadczenia muszę się zgodzić.

Kolejne pytanie wydaje mi się naprawdę pytać, jak zrobić coś podobnego do aplikacji friendw języku C #. Podczas gdy odpowiedzi zazwyczaj dotyczą klas zagnieżdżonych, nie wydaje się to tak eleganckie, jak użycie friendsłowa kluczowego.

Oryginalna książka Design Patterns używa jej regularnie w swoich przykładach.

Podsumowując, dlaczego friendbrakuje go w języku C # i jaki jest sposób (lub sposoby) „najlepszej praktyki” symulowania go w języku C #?

(Nawiasem mówiąc, internalsłowo kluczowe nie jest tym samym, pozwala wszystkim klasom w całym zespole na dostęp do internalelementów, a jednocześnie frienddaje pewnej klasie pełny dostęp do dokładnie jednej innej klasy)

Posiadanie znajomych w programowaniu jest mniej więcej uważane za „brudne” i łatwe do nadużyć. Łamie relacje między klasami i podważa niektóre podstawowe atrybuty języka OO.

To powiedziawszy, jest to fajna funkcja i używałem jej wiele razy w C ++; i chciałbym użyć go również w języku C #. Ale założę się z powodu „czystego” OOness C # (w porównaniu do pseudoOOness C ++) MS zdecydowało, że ponieważ Java nie ma przyjaciela, słowo kluczowe C # również nie powinno (tylko żartuje;))

Mówiąc poważnie: wewnętrzny nie jest tak dobry jak przyjaciel, ale wykonuje zadanie. Pamiętaj, że rzadko zdarza się, że będziesz dystrybuował kod do zewnętrznych programistów nie za pośrednictwem biblioteki DLL; tak długo, jak ty i twój zespół wiecie o klasach wewnętrznych i ich wykorzystaniu, wszystko będzie dobrze.

EDYCJA Pozwól mi wyjaśnić, w jaki sposób słowo kluczowe znajomego podważa OOP.

Prywatne i chronione zmienne i metody są prawdopodobnie jedną z najważniejszych części OOP. Pomysł, że obiekty mogą przechowywać dane lub logikę, z których tylko one mogą korzystać, pozwala napisać implementację funkcjonalności niezależnie od środowiska - i że środowisko nie może zmieniać informacji o stanie, które nie są odpowiednie do obsługi. Korzystając z przyjaciela, łączysz implementacje dwóch klas razem - co jest znacznie gorsze niż w przypadku połączenia ich interfejsu.

Na marginesie. Korzystanie ze znajomego nie polega na naruszeniu enkapsulacji, ale wręcz przeciwnie - na jej wymuszeniu. Podobnie jak akcesoria + mutatory, przeciążanie operatorów, dziedziczenie publiczne, downcasting itp. , Często jest niewłaściwie używane, ale nie oznacza to, że słowo kluczowe nie ma, lub gorzej, złego celu.

Zobacz Konrad Rudolph „s wiadomość w innym wątku, lub jeśli wolisz zobaczyć odpowiedni wpis w C ++ FAQ.

Dla informacji, kolejną powiązaną, ale niezupełnie tą samą rzeczą w .NET jest [InternalsVisibleTo], która pozwala zespołowi wyznaczyć inny zespół (taki jak zespół testu jednostkowego), który (skutecznie) ma „wewnętrzny” dostęp do typów / elementów w oryginalny zespół.

Powinieneś być w stanie osiągnąć te same rzeczy, których używa "przyjaciel" w C ++, używając interfejsów w C #. Wymaga to wyraźnego zdefiniowania, które elementy są przekazywane między dwiema klasami, co jest dodatkową pracą, ale może również ułatwić zrozumienie kodu.

Jeśli ktoś ma przykład rozsądnego użycia „przyjaciela”, którego nie można symulować za pomocą interfejsów, udostępnij go! Chciałbym lepiej zrozumieć różnice między C ++ i C #.

Dzięki friendC ++ projektant ma precyzyjną kontrolę nad tym, na kogo są narażeni członkowie prywatni *. Ale jest zmuszony zdemaskować każdego z prywatnych członków.

Dzięki internalprojektantowi C # ma precyzyjną kontrolę nad zestawem członków prywatnych, które udostępnia. Oczywiście może ujawnić tylko jednego członka prywatnego. Ale zostanie narażony na wszystkie klasy w zespole.

Zazwyczaj projektant chce udostępnić tylko kilka metod prywatnych wybranym wybranym klasom. Na przykład we wzorcu fabrycznym klasy może być pożądane, aby instancja klasy C1 była tworzona tylko przez klasę fabryczną CF1. Dlatego klasa C1 może mieć chronionego konstruktora i przyjazną fabrykę klasy CF1.

Jak widać, mamy 2 wymiary, wzdłuż których można naruszyć enkapsulację. friendnarusza to wzdłuż jednego wymiaru, internalrobi to wzdłuż drugiego. Które z nich jest gorszym naruszeniem koncepcji enkapsulacji? Ciężko powiedzieć. Ale byłoby miło mieć oba friendi internaldostępne. Ponadto dobrym dodatkiem do tych dwóch byłby trzeci typ słowa kluczowego, który byłby używany na zasadzie członek po członku (podobny internal) i określa klasę docelową (podobny friend).

* Dla zwięzłości użyję słowa „prywatny” zamiast „prywatny i / lub chroniony”.

- Nick

W rzeczywistości C # daje możliwość uzyskania tego samego zachowania w czysty sposób OOP bez specjalnych słów - to prywatne interfejsy.

Jeśli chodzi o pytanie Jaki jest odpowiednik C # znajomego?został oznaczony jako duplikat tego artykułu i nikt tam nie proponuje naprawdę dobrej realizacji - w tym miejscu pokażę odpowiedź na oba pytania.

Główna idea wzięła się stąd: czym jest prywatny interfejs?

Powiedzmy, że potrzebujemy klasy, która mogłaby zarządzać instancjami innych klas i wywoływać na nich specjalne metody. Nie chcemy umożliwiać wywoływania tych metod innym klasom. To jest dokładnie to samo, co słowo kluczowe znajomego c ++ robi w świecie c ++.

Myślę, że dobrym przykładem w praktyce może być wzorzec Full State Machine, w którym jakiś kontroler aktualizuje obiekt stanu bieżącego i przełącza w razie potrzeby inny obiekt stanu.

Mógłbyś:

• Najłatwiejszy i najgorszy sposób upublicznienia metody Update () - mam nadzieję, że wszyscy zrozumieją, dlaczego jest ona zła.
• Następnym sposobem jest oznaczenie go jako wewnętrznego. Wystarczy, jeśli umieścisz swoje klasy w innym zestawie, ale nawet wtedy każda klasa w tym zestawie może wywołać każdą metodę wewnętrzną.
• Użyj prywatnego / chronionego interfejsu - i poszedłem w ten sposób.

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
    }
}

A co z dziedziczeniem?

Musimy zastosować technikę opisaną w części Ponieważ jawne implementacje elementów interfejsu nie mogą być deklarowane jako wirtualne i oznaczać IState jako chronione, aby dać możliwość czerpania również ze sterownika.

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()");
    }
}

I na koniec przykład, jak przetestować dziedziczenie klas kontrolerów: ControllerTest.cs

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

Mam nadzieję, że obejmuję wszystkie sprawy i moja odpowiedź była przydatna.

Przyjaciel jest niezwykle przydatny podczas pisania testu jednostkowego.

Chociaż wiąże się to z niewielkim zanieczyszczeniem deklaracji klasy, jest to również wymuszone przez kompilator przypomnienie o tym, jakie testy faktycznie mogą mieć wpływ na wewnętrzny stan klasy.

Bardzo przydatnym i czystym idiomem, który znalazłem, jest posiadanie zajęć fabrycznych, dzięki czemu zaprzyjaźniają się z tworzonymi przez siebie przedmiotami, które mają chronionego konstruktora. Mówiąc dokładniej, wtedy miałem jedną fabrykę odpowiedzialną za tworzenie pasujących obiektów renderujących dla obiektów tworzących raporty, renderowanie w danym środowisku. W tym przypadku masz jeden punkt wiedzy na temat relacji między klasami tworzącymi raporty (takimi jak bloki obrazu, pasy układu, nagłówki stron itp.) I odpowiadającymi im obiektami renderującymi.

C # brakuje słowa kluczowego „przyjaciel” z tego samego powodu, dla którego brakuje deterministycznego zniszczenia. Zmieniające się konwencje sprawiają, że ludzie czują się inteligentni, tak jakby ich nowe sposoby były lepsze od starych. Chodzi o dumę.

Mówienie, że „klasy znajomych są złe” jest tak krótkowzroczne, jak inne niekwalifikowane stwierdzenia, takie jak „nie używaj goto” lub „Linux jest lepszy niż Windows”.

Słowo kluczowe „przyjaciel” w połączeniu z klasą proxy jest świetnym sposobem na ujawnienie tylko niektórych części klasy konkretnym innym klasom. Klasa proxy może działać jako zaufana bariera dla wszystkich innych klas. „public” nie zezwala na takie kierowanie, a użycie opcji „chroniony” w celu uzyskania efektu z dziedziczeniem jest niezręczne, jeśli tak naprawdę nie ma pojęciowego „związku”.

Możesz zbliżyć się do „znajomego” C ++ za pomocą słowa kluczowego C # „internal” .

W rzeczywistości nie jest to problem z C #. Jest to podstawowe ograniczenie w IL. C # jest przez to ograniczony, podobnie jak każdy inny język .Net, który stara się być weryfikowalny. To ograniczenie obejmuje również klasy zarządzane zdefiniowane w C ++ / CLI ( sekcja Spec 20.5 ).

Biorąc to pod uwagę, myślę, że Nelson ma dobre wytłumaczenie, dlaczego jest to zła rzecz.

Przestańcie usprawiedliwiać to ograniczenie. przyjaciel jest zły, ale wewnętrzny jest dobry? są takie same, tylko ten przyjaciel daje ci dokładniejszą kontrolę nad tym, kto ma dostęp, a kto nie.

Ma to na celu egzekwowanie paradygmatu enkapsulacji? więc musisz napisać metody akcesora i co teraz? jak masz powstrzymywać wszystkich (oprócz metod klasy B) przed wywoływaniem tych metod? nie możesz, ponieważ nie możesz tego kontrolować, ponieważ brakuje „przyjaciela”.

Żaden język programowania nie jest idealny. C # jest jednym z najlepszych języków, jakie widziałem, ale głupie usprawiedliwienia dla brakujących funkcji nie pomagają nikomu. W C ++ brakuje mi łatwego systemu zdarzeń / delegowania, refleksji (+ automatycznego de / serializacji) i foreach, ale w C # brakuje mi przeciążenia operatora (tak, mów mi, że go nie potrzebujesz), parametrów domyślnych, stałej którego nie można obejść, wielokrotne dziedziczenie (tak, mów mi, że go nie potrzebujesz, a interfejsy były wystarczającym zamiennikiem) oraz możliwość podjęcia decyzji o usunięciu instancji z pamięci (nie, nie jest to strasznie złe, chyba że jesteś majsterkowicz)

Istnieje. InternalsVisibleToAttribute od .Net 3, ale podejrzewam, że dodali go tylko do testowania zespołów po wzroście testów jednostkowych. Nie widzę wielu innych powodów, aby z niego korzystać.

Działa na poziomie zespołu, ale wykonuje pracę tam, gdzie nie działa wewnętrzny; oznacza to, że chcesz rozpowszechniać zestaw, ale chcesz, aby inny niepodzielony zespół miał uprzywilejowany dostęp do niego.

Zupełnie słusznie wymagają silnego klucza do zgromadzenia przyjaciół, aby uniknąć tworzenia udawanego przyjaciela obok chronionego zgromadzenia.

Przeczytałem wiele sprytnych komentarzy na temat słowa kluczowego „przyjaciel” i zgadzam się, co to jest przydatne, ale myślę, że to „wewnętrzne” słowo kluczowe jest mniej przydatne i oba nadal są złe dla czystego programowania OO.

Co mamy? (mówiąc o „przyjacielu”, mówię także o „wewnętrznym”)

• czy użycie „przyjaciela” sprawia, że ​​kod jest mniej czysty w odniesieniu do oo?

• tak;

• nie użycie „przyjaciela” czyni kod lepszym?

• nie, nadal musimy nawiązywać prywatne relacje między klasami i możemy to zrobić tylko wtedy, gdy przełamiemy naszą piękną enkapsulację, więc to też nie jest dobre, mogę powiedzieć, że to jeszcze bardziej złe niż użycie „przyjaciela”.

Używanie znajomego powoduje pewne problemy lokalne, nie używanie go powoduje problemy dla użytkowników bibliotek kodów.

wspólne dobre rozwiązanie dla języka programowania widzę tak:

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

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

Co o tym myślisz? Myślę, że to najczęstsze i czysto obiektowe rozwiązanie. Możesz otworzyć dostęp do dowolnej metody dowolnej klasy.

Odpowiem tylko na pytanie „jak”.

Jest tu tak wiele odpowiedzi, jednak chciałbym zaproponować rodzaj „wzorca projektowego”, aby osiągnąć tę funkcję. Użyję prostego mechanizmu językowego, który obejmuje:

• Interfejsy
• Klasa zagnieżdżona

Na przykład mamy 2 główne klasy: studenckie i uniwersyteckie. Student posiada GPA, do którego dostęp ma tylko uniwersytet. Oto kod:

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();
}

Podejrzewam, że ma to coś wspólnego z modelem kompilacji C # - budowaniem IL kompilacji JIT w czasie wykonywania. tj. ten sam powód, dla którego generyczne C # zasadniczo różnią się od generycznych C ++.

możesz zachować prywatność i używać refleksji do wywoływania funkcji. Środowisko testowe może to zrobić, jeśli poprosisz go o przetestowanie funkcji prywatnej

Zwykle regularnie korzystałem z przyjaciela i nie sądzę, aby było to naruszenie OOP lub oznaka jakiejkolwiek wady projektowej. Jest kilka miejsc, w których jest to najbardziej wydajny sposób na właściwy koniec z najmniejszą ilością kodu.

Jednym konkretnym przykładem jest tworzenie zestawów interfejsów, które zapewniają interfejs komunikacyjny z innym oprogramowaniem. Zasadniczo istnieje kilka klas wagi ciężkiej, które radzą sobie ze złożonością protokołu i specyfikami równorzędnymi, i zapewniają stosunkowo prosty model łączenia / odczytu / zapisu / przekazywania / rozłączania obejmujący przekazywanie wiadomości i powiadomień między aplikacją kliencką a zestawem. Te wiadomości / powiadomienia muszą być zapakowane w klasy. Atrybutami na ogół trzeba manipulować przez oprogramowanie protokołu, ponieważ jest ich twórcą, ale wiele rzeczy musi pozostać tylko do odczytu dla świata zewnętrznego.

Po prostu głupie jest stwierdzenie, że naruszenie protokołu OOP powoduje, że klasa protokołowa / „twórca” ma intymny dostęp do wszystkich utworzonych klas - klasa twórców musiała nieco podszywać się pod każdym względem danych. Najważniejsze dla mnie jest zminimalizowanie wszystkich dodatkowych wierszy kodu BS, do których zwykle prowadzi model „OOP for OOP's Sake”. Dodatkowe spaghetti po prostu powoduje więcej błędów.

Czy ludzie wiedzą, że możesz zastosować wewnętrzne słowo kluczowe na poziomie atrybutu, właściwości i metody? Nie dotyczy to tylko deklaracji klasy najwyższego poziomu (choć wydaje się, że większość przykładów to pokazuje).

Jeśli masz klasę C ++, która używa słowa kluczowego friend i chcesz emulować ją w klasie C #: 1. zadeklaruj publiczną klasę C # 2. zadeklaruj wszystkie atrybuty / właściwości / metody, które są chronione w C ++, a zatem dostępne dla znajomych jako wewnętrzny w C # 3. utwórz właściwości tylko do odczytu dla publicznego dostępu do wszystkich wewnętrznych atrybutów i właściwości

Zgadzam się, że nie jest to w 100% to samo co przyjaciel, a test jednostkowy jest bardzo cennym przykładem potrzeby czegoś takiego jak przyjaciel (podobnie jak kod rejestrujący analizator protokołu). Jednak wewnętrzny zapewnia ekspozycję na klasy, które chcesz mieć, a [InternalVisibleTo ()] obsługuje resztę - wygląda na to, że narodził się specjalnie do testu jednostkowego.

O ile przyjaciel „jest lepszy, ponieważ możesz wyraźnie kontrolować, które klasy mają dostęp” - co do cholery jest bandą podejrzanych złych klas, które robią w tym samym zgromadzeniu? Podziel swoje podziały na partycje!

Przyjaźń można symulować, oddzielając interfejsy i implementacje. Pomysł jest następujący: „ Wymagaj konkretnego wystąpienia, ale ogranicz dostęp do budowy tego wystąpienia ”.

Na przykład

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) { }
}

Pomimo tego, że ItsMeYourFriend()jest to Friendklasa publiczna, może uzyskać do niej dostęp, ponieważ nikt inny nie może uzyskać konkretnego wystąpienia Friendklasy. Ma prywatnego konstruktora, a fabrykaNew() metoda zwraca interfejs.

Zobacz mój artykuł Znajomi i członkowie interfejsu wewnętrznego bezpłatnie z kodowaniem interfejsów, aby uzyskać szczegółowe informacje.

Niektórzy sugerują, że korzystanie z przyjaciela może wymknąć się spod kontroli. Zgodziłbym się, ale to nie zmniejsza jego przydatności. Nie jestem pewien, czy przyjaciel koniecznie rani paradygmat OO bardziej niż upublicznianie wszystkich członków twojej klasy. Z pewnością język pozwoli upublicznić wszystkich członków, ale jest to zdyscyplinowany programista, który unika tego rodzaju wzorców projektowych. Podobnie zdyscyplinowany programista zastrzegłby używanie przyjaciela w szczególnych przypadkach, w których ma to sens. W niektórych przypadkach wydaje mi się, że wewnętrzne ujawniają się za bardzo. Po co wystawiać klasę lub metodę na wszystko w zestawie?

Mam stronę ASP.NET, która dziedziczy moją własną stronę bazową, która z kolei dziedziczy System.Web.UI.Page. Na tej stronie mam kod, który obsługuje raportowanie błędów użytkownika końcowego dla aplikacji w metodzie chronionej

ReportError("Uh Oh!");

Teraz mam kontrolę użytkownika zawartą na stronie. Chcę, aby kontrola użytkownika mogła wywoływać metody raportowania błędów na stronie.

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

Nie można tego zrobić, jeśli metoda ReportError jest chroniona. Mogę ustawić go jako wewnętrzny, ale jest on narażony na dowolny kod w zestawie. Chcę tylko, aby był narażony na elementy interfejsu użytkownika, które są częścią bieżącej strony (w tym kontrolki podrzędne). Mówiąc dokładniej, chcę, aby moja podstawowa klasa kontrolna zdefiniowała dokładnie te same metody raportowania błędów i po prostu wywołała metody na stronie podstawowej.

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

Uważam, że coś takiego jak znajomy może być przydatne i zaimplementowane w języku bez zmniejszania „OO” języka, być może jako atrybutów, dzięki czemu możesz mieć klasy lub metody zaprzyjaźnienia się z konkretnymi klasami lub metodami, umożliwiając programistom określony dostęp. Być może coś w rodzaju ... (pseudo kod)

[Friend(B)]
class A {

    AMethod() { }

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

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

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

W przypadku mojego poprzedniego przykładu być może mam coś takiego jak poniżej (można argumentować semantykę, ale staram się pojąć ten pomysł):

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);
    }
}

Moim zdaniem koncepcja przyjaciela nie wiąże się z większym ryzykiem niż upublicznienie lub stworzenie publicznych metod lub właściwości dostępu do członków. Jeśli cokolwiek przyjaciel pozwala na inny poziom szczegółowości w dostępie do danych i pozwala zawęzić tę dostępność zamiast poszerzać ją o wewnętrzną lub publiczną.

Jeśli pracujesz z C ++ i zauważysz, że używasz słowa kluczowego „przyjaciel”, jest to bardzo silna oznaka, że ​​masz problem z projektem, bo dlaczego, do cholery, klasa musi uzyskać dostęp do prywatnych członków innej klasy?

Bsd

Stwierdzono, że przyjaciele ranią czystą OOness. Które zgadzam się.

Stwierdzono również, że przyjaciele pomagają w enkapsulacji, co również zgadzam się.

Myślę, że przyjaźń powinna zostać dodana do metodologii OO, ale nie tak jak w C ++. Chciałbym mieć pewne pola / metody, do których moja klasa przyjaciół ma dostęp, ale NIE chciałbym, aby miały dostęp do WSZYSTKICH moich pól / metod. Tak jak w prawdziwym życiu, pozwalam moim znajomym na dostęp do mojej osobistej lodówki, ale nie pozwalam im na dostęp do mojego konta bankowego.

Można to zaimplementować w następujący sposób

    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);
        }
    }

To oczywiście wygeneruje ostrzeżenie kompilatora i zaszkodzi inteligencji. Ale to zadziała.

Na marginesie, myślę, że pewien programista powinien wykonać testowanie bez dostępu do prywatnych członków. jest to całkiem poza zakresem, ale spróbuj przeczytać o TDD. jednak jeśli nadal chcesz to zrobić (mając przyjaciół podobnych do c ++), spróbuj czegoś takiego

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

więc piszesz cały kod bez definiowania UNIT_TESTING, a gdy chcesz przeprowadzić testowanie jednostek, dodajesz #define UNIT_TESTING do pierwszego wiersza pliku (i piszesz cały kod, który wykonuje testowanie jednostek w #if UNIT_TESTING). Z tym należy obchodzić się ostrożnie.

Ponieważ uważam, że testowanie jednostkowe jest złym przykładem użycia znajomych, podam przykład, dlaczego uważam, że przyjaciele mogą być dobrzy. Załóżmy, że masz system łamania (klasę). Z czasem system łamania ulega zużyciu i wymaga remontu. Teraz chcesz, aby naprawił to tylko licencjonowany mechanik. Aby ten przykład był mniej trywialny, powiedziałbym, że mechanik użyłby swojego osobistego (prywatnego) śrubokręta, aby go naprawić. Dlatego klasa mechaników powinna być przyjacielem klasy BreakSystem.

Przyjaźń można również symulować za pomocą „agentów” - niektórych klas wewnętrznych. Rozważ następujący przykład:

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.
  }
}

Może być znacznie prostsze, gdy jest używany do dostępu tylko do elementów statycznych. Korzyści z takiego wdrożenia polegają na tym, że wszystkie typy są zadeklarowane w wewnętrznym zakresie klas przyjaźni i, w przeciwieństwie do interfejsów, umożliwiają dostęp do elementów statycznych.