Warum stellt C # das C ++ - Stil-Friend-Keyword nicht zur Verfügung?

Freunde, bei der Programmierung ist mehr oder weniger als "schmutzig" und leicht zu missbrauchen. Es bricht die Beziehungen zwischen den Klassen und räumt mit einigen grundlegenden Eigenschaften einer OO-Sprache.

That being said, es ist ein nettes feature und ich habe es viele Male selbst in C++; und möchte, um es in C# auch. Aber ich Wette, dass da von C#'s "Reine" OOness (im Vergleich zu C++'s pseudo OOness) MS entschieden, weil Java hat keine friend-Schlüsselwort in C# sollte nicht entweder (nur ein Scherz ;))

Auf eine ernste beachten Sie: die interne ist nicht so gut, als Freund, aber es tut den job zu erledigen. Denken Sie daran, dass es selten ist, dass Sie verteilen Ihren code zu 3rd-party-Entwickler nicht über eine DLL, so lange, wie Sie und Ihr team wissen über die internen Klassen und deren Verwendung Sie sollten in Ordnung sein.

BEARBEITEN Lassen Sie mich klarstellen, wie das friend-Schlüsselwort untergräbt OOP.

Private und protected Variablen und Methoden sind vielleicht der wichtigste Teil der OOP. Die Idee, die Objekte halten kann-Daten oder-Logik, die nur Sie verwenden können, können Sie schreiben Sie Ihre Implementierung von Funktionen unabhängig von Ihrer Umgebung - und, dass Sie Ihre Umwelt nicht verändern können Status-Informationen, dass es nicht geeignet. Von mit Freundin Sie sind auf der Kopplung zweier Klassen-Implementierungen zusammen - und das ist viel schlimmer dann, wenn Sie gerade gekoppelt, Ihre Schnittstelle.

InformationsquelleAutor der Antwort nlaq

Zur info, in einem anderen Zusammenhang-aber-nicht-ganz-der-gleichen Sache .NET ist [InternalsVisibleTo] können einer assembly festlegen einer anderen Baugruppe (z.B. ein unit test, assembly) , (effektiv), "internen" Zugang zu Arten/Mitglieder in der ursprünglichen assembly.

InformationsquelleAutor der Antwort Marc Gravell

Mit friend eine C++ - designer hat eine genaue Kontrolle über denen der privaten* Mitglieder ausgesetzt sind. Aber, er ist gezwungen zu entlarven jeder von den privaten Mitgliedern.

Mit internal eine C# - designer hat eine genaue Kontrolle über die privaten Mitglieder, die er aufdeckt. Offensichtlich kann er aussetzen, nur ein einziger private member. Aber, es wird ausgesetzt, bis alle Klassen in der assembly.

In der Regel ein designer wünscht, stellen nur einige private Methoden, um ausgewählte paar andere Klassen. Zum Beispiel, in einer Klasse-Fabrik-Muster kann es wünschenswert sein, die Klasse C1 instanziiert wird nur durch die Klasse factory-CF1. Daher Klasse C1 haben einen protected-Konstruktor und ein Freund class factory CF1.

Wie Sie sehen können, haben wir 2 Dimensionen, entlang denen die Kapselung kann durchbrochen werden. friend Verstöße gegen Sie entlang einer dimension, internal hat es entlang der anderen. Das ist ein schlimmer Bruch in der Kapselung Konzept? Schwer zu sagen. Aber es wäre schön beides zu haben friend und internal erhältlich. Außerdem eine gute Ergänzung zu diesen beiden wäre die 3. Art von Schlüsselwort, das verwendet werden würde, über member-by-member-basis (wie internal) und gibt die Ziel-Klasse (wie friend).

* Der Kürze halber verwende ich "private" anstelle von "private und/oder geschützt werden".

- Nick

InformationsquelleAutor der Antwort Nick Alexeev

Freund ist sehr nützlich beim schreiben von unit-test.

Während das kommt zu einem Preis von umweltschädlichen Ihre Klasse Erklärung leicht, es ist auch ein compiler erzwungene Erinnerung an das, was tests eigentlich könnte die Versorgung über den internen Zustand der Klasse.

Sehr nützlich und sauber Redewendung, die ich gefunden habe ist, wenn ich die factory-Klassen, so dass Sie Freunde der Gegenstände, die Sie erstellen, die eine protected-Konstruktor. Genauer gesagt, dies war, als ich hatte eine einzige Fabrik verantwortlich für die Erstellung von passenden rendering-Objekte für report-writer-Objekten, rendering, die zu einer gegebenen Umwelt. In diesem Fall müssen Sie einen einzigen Punkt des Wissens über die Beziehung zwischen der report-writer-Klassen (Dinge wie Bild-Blöcke, layout-bands, Kopfzeilen etc.) und die dazu passenden rendering-Objekte.

InformationsquelleAutor der Antwort Andy Dent

C# fehlt "Freund" - Schlüsselwort aus dem gleichen Grund fehlt deterministische Zerstörung. Ändern von Konventionen macht die Menschen fühlen sich schlau, wie wenn Ihr neue Wege überlegen, um jemand anderes' alten Wege. Es geht um stolz.

Sagen, dass "friend-Klassen sind schlecht" ist so kurzsichtig, wie andere unqualifizierte Aussagen wie "benutze keine gotos" oder "Linux ist besser als Windows".

Den "Freund" keyword Kombination mit einer proxy-Klasse ist eine großartige Möglichkeit, um nur aussetzen bestimmte Teile einer Klasse zu bestimmten anderen Klasse(N). Eine proxy-Klasse kann als eine Vertrauenswürdige Barriere gegen alle anderen Klassen. "öffentlichkeit" nicht zulässt, dass solche Ausrichtung, und mit "geschützt", um die Wirkung bei der Vererbung ist umständlich, wenn es wirklich keine konzeptionelle "ist ein" - Beziehung.

InformationsquelleAutor der Antwort Matthew

Stop Entschuldigungen für diese Einschränkung. Freund ist schlecht, aber die interne ist gut? Sie sind die gleiche Sache, nur, dass Freund gibt Ihnen genauere Kontrolle darüber, wer zugreifen darf und wer nicht.

Dies ist zur Durchsetzung der Kapselung Paradigma? so haben Sie zu schreiben accessor-Methoden und was nun? wie soll man das stoppen jeder (außer den Methoden der Klasse B) aus aufrufen dieser Methoden? Sie können nicht, weil Sie nicht kontrollieren können, dies entweder, weil der fehlende "Freund".

Keine Programmiersprache ist perfekt. C# ist eine der besten Sprachen, die ich gesehen habe, aber dumme Ausreden für fehlende Funktionen, ist niemandem geholfen. In C++ vermisse ich die easy event/delegate-system, Reflexion (+automatische de - /Serialisierung) und foreach, aber in C# ich vermisse operator überladen (ja, die sagen mir immer, dass Sie nicht brauchen), default-Parameter, const, die nicht umgangen werden kann, ist die mehrfache Vererbung (ja, die sagen mir immer, dass Sie nicht brauchen und die Schnittstellen waren ein geeigneter Ersatz) und die Möglichkeit, zu entscheiden, zum löschen einer Instanz aus dem Speicher (keine, dies ist nicht furchtbar schlecht, es sei denn, Sie sind ein Tüftler)

InformationsquelleAutor der Antwort Algoman

Ich habe gelesen, dass viele intelligente Kommentare zu "friend" - Schlüsselwort & ich Stimme dem, was es ist nützliche Sache, aber ich denke, was "interne" Stichwort ist weniger nützlich, & Sie beide immer noch schlecht für Reine OO-Programmierung.

Was wir haben? (Sprichwort über "Freund" ich habe mir auch sagen, über "interne")

• ist mit "Freund" macht den code weniger rein in Bezug auf oo?

• ja;

• ist nicht mit "Freund" macht code besser?

• Nein, wir müssen noch einige private Beziehungen zwischen Klassen & wir können es nur tun, wenn wir brechen unsere schöne Kapselung, so dass es auch nicht gut, ich kann sagen, was es noch mehr übel als mit "Freund".

Mit Freundin macht einige lokale Probleme, die nicht mit macht es Probleme, die für die code-Bibliothek-Nutzer.

die gemeinsame gute Lösung für die Programmierung Sprache, die ich nicht sehen wie diese:

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

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

Was haltet Ihr davon? Ich denke, dass es die häufigsten & Reine Objekt-orientierte Lösung. Sie können open-access-jede Methode, die Sie wählen, um jede Klasse, die Sie möchten.

InformationsquelleAutor der Antwort FadeToBlack

Wenn Sie arbeiten mit C++ und finden Sie Ihr selbst mit friend-Schlüsselwort, es ist ein sehr starkes Indiz dafür, dass Sie haben ein design-Problem, weil, warum zum Teufel eine Klasse benötigt, die Zugriff auf private Mitglieder der anderen Klasse??

InformationsquelleAutor der Antwort bashmohandes

Ich verwendet, um regelmäßig zu verwenden Freund, und ich glaube nicht, dass es ein Verstoß gegen die OOP-oder ein Zeichen für eine Designfehler. Es gibt mehrere Orte, wo es ist das effizienteste Mittel, um das richtige Ende mit der geringsten Menge von code.

Konkreten Beispiel ist es beim erstellen von interface Baugruppen, die eine Kommunikations-Schnittstelle zu einer anderen software. In der Regel gibt es ein paar Schwergewichts-Klassen, die Bewältigung der Komplexität des Protokolls und peer Besonderheiten, und bieten eine relativ einfache verbinden/Lesen/schreiben/weiterleiten/trennen Sie das Modell mit übergeben Nachrichten und Meldungen zwischen der client-Anwendung und der Montage. Diese Nachrichten /Benachrichtigungen werden müssen verpackt in Klassen. Die Attribute müssen in der Regel manipuliert werden, indem die Protokoll-software, wie es ist, Ihren Schöpfer, aber viele Sachen bleiben nur-lese-zu der Außenwelt.

Es ist einfach albern zu erklären, dass es ein Verstoß gegen die OOP für das Protokoll /"creator" - Klasse zu haben Intim Zugriff auf alle erstellten Klassen -- der Schöpfer Klasse musste bit munge jedes bit der Daten auf dem Weg nach oben. Was ich gefunden habe, am wichtigsten ist, zu minimieren alle BS Zeilen extra-code "OOP für OOP 's Sake" - Modell führt in der Regel zu. Extra spaghetti macht einfach mehr bugs.

Haben die Leute wissen, dass Sie anwenden können, die interne keyword-am-Attribut, Eigenschaft, Methode und Ebene? Es ist nicht nur für die top-level Klassen-Deklaration (obwohl die meisten Beispiele scheinen zu zeigen, dass.)

Wenn Sie eine C++ - Klasse, nutzt das friend-Schlüsselwort, und emulieren möchten, die in einer C# - Klasse:
1. deklarieren Sie die C# - Klasse, die öffentliche
2. deklarieren Sie alle Attribute/Eigenschaften/Methoden, die geschützt sind in C++ und damit zugänglich für Freunde als intern in C#
3. erstellen nur-lese Eigenschaften, die für den öffentlichen Zugang zu allen internen Attribute und Eigenschaften

Ich Zustimmen, dass es nicht 100% das gleiche wie Freund-und unit-test ist ein sehr wertvolles Beispiel für die Notwendigkeit von so etwas wie der Freund (als ist-Protokoll-analyzer logging-code). Doch intern stellt die Belichtung auf die Klassen, die Sie haben wollen, Belichtung und [InternalVisibleTo()] übernimmt den rest -- scheint, wie es geboren wurde speziell für unit-Tests.

Soweit friend "sei besser, weil Sie sich explizit Steuern, welche Klassen Zugriff haben" -- was solls es gibt eine Reihe von verdächtigen bösen Klassen in der gleichen assembly in den ersten Platz? Partition Ihre Baugruppen!

InformationsquelleAutor der Antwort Christo

Einige haben vorgeschlagen, dass die Dinge außer Kontrolle geraten kann durch die Verwendung Freund. Dem würde ich Zustimmen, aber das bedeutet nicht vermindern seine Nützlichkeit. Ich bin nicht sicher, dass Freund unbedingt weh tut, das OO-Paradigma nicht mehr, als dass alle Ihre Klasse-Mitglieder öffentlich. Sicherlich ist die Sprache, die Ihnen erlauben, alle Ihre Mitglieder, die öffentlichkeit, aber es ist eine disziplinierte Programmierer, die vermeidet, dass diese Art von design pattern. Ebenfalls eine disziplinierte Programmierer würde behalten uns die Verwendung von "Freund" für bestimmte Fälle, in denen es Sinn macht. Ich fühle innere macht zu viel in einigen Fällen. Warum setzen Sie eine Klasse oder Methode, um alles, was in der Versammlung?

Habe ich eine ASP.NET Seite erbt meine eigene Basis-Seite, die wiederum inherits System.Web.UI.Seite. In dieser Seite habe ich einige code, der verarbeitet die end-user die Fehlerberichterstattung für die Anwendung in einem geschützten Methode

ReportError("Uh Oh!");

Nun, ich habe ein Benutzersteuerelement, die in der Seite enthalten. Ich möchte die Benutzer Steuern zu können, rufen Sie die error-reporting-Methoden in der Seite.

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

Kann es nicht tun, wenn die ReportError-Methode ist geschützt. Ich kann machen Sie es intern, aber es ausgesetzt ist, zu jedem code in der assembly. Ich will ihn ausgesetzt, um die UI-Elemente, die Teil der aktuellen Seite (einschließlich der untergeordneten Steuerelemente). Genauer gesagt, möchte ich meine base control-Klasse definieren, die genau die gleiche Fehler-reporting-Methoden, und einfach aufrufen von Methoden in der base-Seite.

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

Ich glaube, dass so etwas wie Freund nützlich sein könnte, und implementiert in der Sprache, ohne dass die Sprache weniger "OO" wie, vielleicht als Attribute, so dass Sie können Klassen oder Methoden sein, Freunde auf bestimmte Klassen oder Methoden, so dass die Entwickler zu sehr spezifischen Zugang. Vielleicht so etwas wie...(pseudo-code)

[Friend(B)]
class A {

    AMethod() { }

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

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

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

Im Fall meiner vorherigen Beispiel, das vielleicht so etwas wie die folgende (man kann argumentieren, Semantik, sondern ich versuche nur auf die Idee kommen quer):

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

Wie ich es sehe, ist der Freund Konzept hat nicht mehr Risiko als Dinge öffentlich zu machen, oder das erstellen von öffentlichen Methoden und Eigenschaften für den Zugriff auf Mitglieder. Wenn alles friend erlaubt einer anderen Ebene der Granularität, in der Zugänglichkeit von Daten und ermöglicht es Ihnen, zu schmal, dass die Zugänglichkeit eher als Erweiterung mit internen oder öffentlichen.

InformationsquelleAutor der Antwort Scott Forbes

Die Freundschaft kann auch simuliert werden, indem "agents" - einige innere Klassen. Betrachten Sie Folgendes Beispiel:

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

Es könnte sein, viel einfacher, wenn der Zugriff nur auf statische Mitglieder.
Vorteile für eine solche Umsetzung ist, dass alle Typen deklariert sind, die in dem inneren Umfang der Freundschaft-Klassen und, im Gegensatz zu Schnittstellen, die es ermöglicht, statische member, auf die zugegriffen werden.

InformationsquelleAutor der Antwort Aberro

Felder, ALLE Klassen zugreifen können, Sie sind public.

Felder, NICHT alle anderen Klassen zugreifen können, Sie sind private.

(wenn die Felder gehört (deklariert innen) Basis Klasse, dann sind Sie protected statt)

Felder, nur Ihre Besitzer Klasse können auf Sie zugreifen, sind privateund haben keine Eigenschaften und get-set-Methoden.

Felder, die nur Ihre Besitzer Klasse und einige anderen Klassen zugreifen können, Sie sind private und jede hat spezielle private get-und set-Methoden und - public teilen Methoden.

Einige andere Klassen, die ebenfalls Zugriff auf diese Felder haben einige private Bereichen delegieren Arten und spezielle public direkte Methoden.

Beispiel:

class A
{
    private int integer; //In the meantime, it seems that only A can access this integer
    private int GetInteger() //Get method is not public, because we don't want all other classes to use this integer
    {
        return this.integer;
    }
    private void SetInteger(int value) //Set method is not public, because we don't want all other classes to modify this integer
    {
        this.integer = value;
    }
    public void Share(ref B b) //I use the 'ref' keyword, to prevent the 'null' value in this argument, but if you call this method in a constructor of B, or in one of its methods, so you will have to remove the 'ref' keyword, or make overload of the same method without the 'ref' keyword, because 'ref this' is not allowed
    {
        b.DirectGetIntegerAndSetIntegerMethods(this.GetInteger, this.SetInteger);
    }
    public void PrintInteger()
    {
        Console.WriteLine(this.integer);
    }
}
class B //This class can access the 'integer' of A too, i.e. the 'integer' of A is "public" only for B
{
    private Func<int> GetInteger; //Will execute the 'GetInteger' method of A
    private Action<int> SetInteger; //Will execute the 'SetInteger' method of A
    public void DirectGetIntegerAndSetIntegerMethods(Func<int> getInteger, Action<int> setInteger)
    {
        this.GetInteger = getInteger;
        this.SetInteger = setInteger;
    }
    public void Increment()
    {
        this.SetInteger(this.GetInteger() + 1);
    }
}
class Program
{
     static void Main(string[] args)
     {
         A a = new A(); //Created new instance of A, and also new Int32 was initialized inside it and set to its default value 0, but unable to get or set its value, only just print it.
         a.PrintInteger();
         B b = new B(); //Must create new instance of B, in order to change the integer of A to some value. For example, I will use b, to change the integer of a to 3
         a.Share(ref b); //But before the change, I must tell 'a' to share his GetInteger and SetInteger methods to 'b', so 'b' will also be able execute them, through his Func<int> and Action<int> delegates, because GetInteger and SetInteger methods of A are private and cannot be executed directly. 
         for (int i = 0; i < 3; i++)
            b.Increment();
         a.PrintInteger(); //Print the integer of 'a' again after change.
         //Now the output of the console is:
         //0
         //3
     }
}

Muss man wissen, dass mit dem 'Freund' - Schlüsselwort von C++ ist, um zu ermöglichen, dass einige Klassen zu teilen Ihre privaten Mitglieder zu einigen anderen Klassen direkt.

Weil der, der 'Freund' - Schlüsselwort nicht vorhanden ist in C#, Klassen, die keine Möglichkeit haben, teilen Ihre privaten Felder zu einigen anderen Klassen direktaber es ist Weise zu simulieren, die es in der Tat, wie ich oben gezeigt.

Wissen Sie, dass der 'Freund' - Schlüsselwort von C++ kann auch ermöglichen, bei der Umsetzung einiger Funktionen, die Zugriff auf private Mitglieder einige Instanzen von Klassen-Typen?

Die Antwort ist ja, und ich werde Ihnen zeigen, wie Sie simulieren diese auch in C#:

Beispiel:

using System;
using System.Reflection; //New namespace is added
using System.Diagnostics; //Another new namespace is added too

class Person
{
    private readonly StackTrace st = new StackTrace(); //Helper object
    private readonly MethodInfo mi = typeof(Program).GetMethod("Foo"); //The MethodInfo of the method Foo, which will be declared and defined in class Program later, is the friend of the class Person
    //Both objects above are readonly, because they always reference the same objects that they were initialized with.
    private string name_of_his_dog; //Only Person can access this field
    private string GetTheNameOfHisDog() //Not public so that not all methods will be able to get this name
    {
        return this.name_of_his_dog;
    }
    private void SetTheNameOfHisDog(string new_name) //Not public so that not all methods will be able to set this name
    {
        this.name_of_his_dog = new_name;
    }
    public Func<string> ShareTheGetTheNameOfHisDogMethod() //Returns null, if the previous method that called this method is not friend of this class Person
    {
        if (this.st.GetFrame(1).GetMethod() == this.mi)
            return this.GetTheNameOfHisDog;
        return null;
    }
    public Action<string> ShareTheSetTheNameOfHisDogMethod() //Same as above
    {
        if (this.st.GetFrame(1).GetMethod() == this.mi)
            return this.SetTheNameOfHisDog;
        return null;
    }
    public void PrintTheNameOfHisDog()
    {
        Console.WriteLine(this.name_of_his_dog);
    }
}
class Program
{
    static void Main(string[] args)
    {
        Person person = Foo();
        person.PrintTheNameOfHisDog();
        Func<string> getTheNameOfHisDog = person.ShareTheGetTheNameOfHisDogMethod(); //returns null, Main is not friend of Person
        Action<string> setTheNameOfHisDog = person.ShareTheSetTheNameOfHisDogMethod(); //returns null too, for the same reason
       setTheNameOfHisDog("Pointer"); //Runtime Error: Object reference not set to an instance of an object
       Console.WriteLine(getTheNameOfHisDog()); //Same runtime error
       //Output before runtime error:
       //Boxer
       //Boxer
    }
    public static Person Foo() //Only this method can get and set the name of the dog that belongs to the person
    {
        Person person = new Person();
        Func<string> getTheNameOfHisDog = person.ShareTheGetTheNameOfHisDogMethod();
        Action<string> setTheNameOfHisDog = person.ShareTheSetTheNameOfHisDogMethod();
        setTheNameOfHisDog("Boxer");
        Console.WriteLine(getTheNameOfHisDog());
        return person;
    }
}

Ich muss zugeben, dass bevor ich gepostet diesen code, ich wusste nicht, wie um herauszufinden, die MethodInfo von der vorherigen Methode, die die aktuelle Methode aufgerufen wurde, aber Firas Assaad ' s Antwort hat mir geholfen, Dank ihm zu.

Wie finde ich die Methode, die die aktuelle Methode aufgerufen wurde?

Er schlug vor, mit der System.Diagnostics.StackTrace Klasse

Hoffe, Sie haben meine Idee, und das hilft und beantwortet deine Frage.

Ich nicht finden, diese Antwort irgendwo im internet, ich dachte über diese Idee von mir mit meinem Gehirn.

InformationsquelleAutor der Antwort Farewell Stack Exchange