friend klassen in c#?

DEvent

Hallo
ich habe eine Daten-Klasse ( Daten ), die daten für eine andere Klasse A speichert.
Die Daten sollen aber nur von der Klasse A geschrieben werden können und von anderen Klasse B..Z nur gelesen werden können.
Wie macht man das in C#?
in C++ sehe das so aus:

class Daten
{
   friend class A;
   public:
       /** Get Methoden für die Daten **/
    private:
       /** daten **/
}

Hängt vom Anwendungsfall ab. Manchmal ist eine inner class für sowas cool.

DEvent

ok, ich hab nach inner class gegoogelt, in der C# Deku geschaut nach "inner" geschaut aber nix gefunden.
also was meinst du bitte ?

interpreter

public class Outer {
   Inner i;
   public Outer() {
      i = new Inner();
   }

   private class Inner {
      // Daten
   }
}

interpreter

DEvent schrieb:

ok, ich hab nach inner class gegoogelt, in der C# Deku geschaut nach "inner" geschaut aber nix gefunden.
also was meinst du bitte ?

Dann musst du verdammt ungeschickt googeln. Gleich der 1. Hit unter "inner class" gab eine gute Beschreibung.

DEvent

bin ich zu blöd dazu oder was soll das nützen?
von aussen kann man doch immernoch nicht auf die Daten zugreifen.
Ich will sie ja von aussen lesen können, aber nur von innen beschreiben.

Axo ( hab mir die pdf angeschaut ). Aber da habt ihr mich falsch verstanden. Ich will dass man die Daten einer Klasse von aussen, d.h. von jeder anderen Klasse aus lesen kann, aber dass nur eine spezielle Klasse die Daten setzen kann.
Also wie halt friend in C++

friend ist etwas, was man einfach nicht unbedingt braucht. Die Fälle, wo friend wirklich einen Vorteil gegenüber was anderem bringt, sind so speziell und selten, dass man die Sprache damit nicht belastet hat.
Ich kenne deinen Fall jetzt nicht. Je nachdem könnt eine inner class gut sein, wobei die äußere Klasse getter nach außen hin anbietet.

Outer: Rad
Inner: Speiche
-> Rad hat getter für Zustand der Speichen

Oder du nimmst es in Kauf, dass es theoretisch möglich wäre, dass noch andere Klassen Informationen setzen können.
Es kann sich auch um ein Fehldesign deinerseits handeln.
Muss aber nicht. Und vielleicht ist für deinen Zweck Immutable noch besser? Da kannst getten und setten sehr genau kontrollieren.

class InfoContainer
{
    private Info reference = new Info();

    public Info Informationi {get{...}}
}

Jetzt kann nur noch InfoContainer ein neues Objekt hinsetzen und wenn Info immutable ist, kann keiner anhand der zurückgegebenen Referenz dein Info ändern.

Aaaabeeeer das ist ja nur wildes Rumgerate. Ich weiß ja gar nicht, was für dich jetzt nützlich ist. Deshalb musst du mit der Antwort vorlieb nehmen, dass es kein friend gibt und dich damit trösten, dass es seine Gründe hat. Eine friend-Schnittstelle zu warten ist viel hässlicher.

Es gibt viele Dinge in C++, die in ganz speziellen wenigen Fällen wirklich toll sind, aber sonst sehr oft falsch benutzt werden. Ich habe friend nie so wirklich gebraucht. Kapselung meint ja nicht, dass man sagt, wer nen setter bedienen darf, sondern, dass der setter eben bestimmt, was wirklich gemacht wird und von der Implementierung trennt. Wenn Beziehung zwischen zwei Klassen sehr eng sind, gibt es oft trotzdem bessere Möglichkeiten als friend.

DEvent

Outer: Rad
Inner: Speiche
-> Rad hat getter für Zustand der Speichen

thx jetzt hab ichs verstanden, dass ist genau das was ich wollte

Sowas macht btw. nur Sinn, wenn es nicht sinnvoll ist, einzelne Speichen zu haben, sondern sie immer Teil eines Rades sein müssen.

internal