Design Frage

[Firefighter]

Ok hab das vielleicht bissel falsch erklärt.Am besten nochmal

Ausgangssituation ist die obige. Jetzt denken wir uns in der Dummy Klasse einfach noch eine Property hinzu die es uns erlaubt lesen und schreibend auf die int Variable zuzugreifen.
Ála:

Main.cs

//Dann ist ja sowas hier möglich

Dummy neu = new Dummy();
neu.Property = 100;//das will ich aber umgehen, bzw sowas möchte ich nicht erlauben.

Auf der anderen Seite will ich aber in der Actor Klasse schreibend auf die int Variable zugreifen wollen.
Ála:

Actor.cs

class Actor
{
    private Dictionary<int,Holder> dummys;

    public Actor()
     {
        //....
    }
    public void erhoehen(/*irgendwelche parameter*/)
    {
        dummys[key].wichtigevariable = 100;//durch den Holder der mir zurückgegeben wird, hab ich ja zugriff auf den Dummy.
    }
}

Frage ist also nur, ob es ein Pattern/Workaround gibt um den Zugriff auf eine Membervariable einer Klasse NUR in einer anderen Klasse gibt aber nicht in der "Main"?Hoffe das erklärt etwas mehr.
Ich will nur wissen ob es möglich ist oder nicht, wenn nicht muss ich es mit der Property machen.

[NoAir]

Guten Abend,

also wenn ich dich richtig verstanden habe, sind "Nested Classes" genau das Richtige für dich!

-->

class Acter
{
  private Dictionary<int, Holder> dummys;

  public Acter()
  {
    // ...
  }

  private class Holder
  {
    private Dummy dummy;

    public Holder() { //... }
  }
}

Somit hast du ausschließlich in der Acter-Klasse Zugriff auf die Holder-Klasse. Das ist ja das was du wolltest...hoffe ich :-)!
Gegebenenfalls musst du ein bisschen mit den Zugriffsmodifizierern der Klassen bzw. Konstruktoren rumspielen, um dein gewünschtes Ergebnis zu erhalten!

Wenn ich dich falsch verstanden habe, tut's mir leid :-)!
Grüße

[Firefighter]

Auf jedenfall schonmal ein interessanter Beitrag, jedoch sicherlich nicht das ganze was ich brauche. Schließlich soll es möglich sein, das man unabhängige Instanzen von Holder oder Dummy erzeugen kann Aber ich versuche mal mein Glück mit den Accesoiren.Danke

[NoAir]

Firefighter schrieb:

... Schließlich soll es möglich sein, das man unabhängige Instanzen von Holder oder Dummy erzeugen kann ...

Hehe, dann kannst du die Klasse ja public machen, aber trotzdem eingenestet lassen.

Acter.Dummy test = new Acter.Dummy();

Allerdings wirst du hier wiederum das Problem haben, dass nun die ganzen Properties wieder sichtbar werden... :-)!

Ich denke, so wie du es dir gedacht hast, ist es nicht so einfach möglich, wär aber ne interessante Aufgabe :-)!

Grüße

[Firefighter]

Hehe Stimmt, könnte man machen, würde dann aber dem Nested Prinzip widersprechen, denke ich:) Nun gut, dann muss ich den unschönen Weg gehen, ich dachte es gäbe einen bekannten Workarround oder ein Pattern, da ich keins der mir bekannten darauf anwendbar sah.Aber danke trotzdem für deine Antworten.

[SolidOffline]

Die Lösung wurde doch schon genannt: internal.

Firefighters zweites Posting beinhaltet keinen Grund dagegen.

[Andorxor]

Du könntest das so lösen:

class Dummy
{
	private int wichtigevariable;

	public Dumm()
	{

	}

        public int WV
        {
          get{return wichtigevariable;}
          set
          {
             if(Acter.WVEditErlaubt)
             {
              wichtigevariable =value;
             }
          }
        }

}
class Holder
{
	private Dummy dummy;

	public Holder()
	{
		//...was mit dem Dummy
	}
}
class Acter
{
	private Dictionary<int,Holder> dummys;
        private static bool _WVEditErlaubt=false;

        public bool WVEditErlaubt
        {
           get{return _WVEditErlaubt;}
        }

	public Acter()
 	{
		//....
	}
	public void erhoehen(/*irgendwelche parameter*/)
	{
                 _WVEditErlaubt=true;
		//hier muss was mit der variable von Dummy gemacht werden
                _WVEditErlaubt = false;
	}
}

[Shade Of Mine]

Ich sehe das Problem nicht.

Wenn du nicht willst dass man den Dummy von Actor ändern kann, dann lass Actor immer ein readonly view von Dummy hergeben.

internal ist dann gut wenn niemand ein Dummy kennen können soll - aber das ist wieder ein komplett anderer weg.

[SolidOffline]

Shade Of Mine schrieb:

Ich sehe das Problem nicht.

Wenn du nicht willst dass man den Dummy von Actor ändern kann, dann lass Actor immer ein readonly view von Dummy hergeben.

internal ist dann gut wenn niemand ein Dummy kennen können soll - aber das ist wieder ein komplett anderer weg.

public class Dummy {
    internal int p_WichtigeVariable;

    public void Dumm() {
      //... 
    }
  }

Nicht die Klasse "internal" machen, sondern den Member.

[NoAir]

Hallo,

"internal" geht nur, wenn er zwei Assemblys hat (.dll + .exe).
Hat er nur eine (.exe) ist "internal" mit "public" gleichgestellt und somit komplett fürn Eimer.

Grüße

P.S. Will er eine Lib entwickeln, stellt sich dieses Problem natürlich erst gar nicht. Ich denke jedoch, dass er die 3 Klassen in seinem Projekt benutzen möchte?!

[SolidOffline]

NoAir schrieb:

Hallo,

"internal" geht nur, wenn er zwei Assemblys hat (.dll + .exe).
Hat er nur eine (.exe) ist "internal" mit "public" gleichgestellt und somit komplett fürn Eimer.

Grüße

P.S. Will er eine Lib entwickeln, stellt sich dieses Problem natürlich erst gar nicht. Ich denke jedoch, dass er die 3 Klassen in seinem Projekt benutzen möchte?!

Wenn es sein Projekt ist und nur er daran arbeitet, hat er kein Problem damit die Klassen in eine eigene Assembly auszulagern, wenn er die Klassen für andere als Lib bereitstellen will, hat er auch "kein Problem" damit sie in eine eigene Assembly auszulagern...

Wo genau liegt das Problem? Von ihm selbst habe ich als Einwand nur gelesen, dass es eine Konsolenanwendung ist, was natürlich kein gültiger Einwand ist.

[NoAir]

Ja sicher, aber er wollte anfangs auch nur wissen, ob es ein Pattern dazu gibt.

Das mit den Assemblys und deren Sichtbarkeit ist meiner Meinung nach nur ein Workaround und hat nichts mit einem Pattern im ursprünglichen Sinne zu tun

[SolidOffline]

NoAir schrieb:

Ja sicher, aber er wollte anfangs auch nur wissen, ob es ein Pattern dazu gibt.

Das mit den Assemblys und deren Sichtbarkeit ist meiner Meinung nach nur ein Workaround und hat nichts mit einem Pattern im ursprünglichen Sinne zu tun

Also meinem Verständnis nach ist "internal" kein "Workaround", sondern genau für solche Fälle da...

Und wenn's schonmal da ist... sollte man es auch nutzen.

[Firefighter]

Hehe danke für eure große Anteilnahme, die Postings die ich gelesen habe, haben mir auf jedenfall sehr geholfen, vielen Dank für eure Meinungen.

[Firefighter]

Sagen wir es mal einfach ich will sowas wie in C++ mit friend auch in C# machen.Anscheint geht das aber nicht einfach, dachte mir das ich dafür nen Wrapper schreibe, ich werde es euch wissen lassen wenn ich weiter bin.

[SolidOffline]

Firefighter schrieb:

Sagen wir es mal einfach ich will sowas wie in C++ mit friend auch in C# machen.Anscheint geht das aber nicht einfach, dachte mir das ich dafür nen Wrapper schreibe, ich werde es euch wissen lassen wenn ich weiter bin.

Hallo? Jemand zuhause? Genau dafür ist der Zugriffsmodifizierer "internal" gedacht, wobei die "friends" halt in einer Assembly zusammengefasst werden (dass es auch friend-assemblies gibt, lass ich mal aussen vor). Woran scheitert es denn nun?

[Firefighter]

Öhm da bin ich ehrlich gesagt, nicht der Meinung. Wenn ich in C++ mit friend arbeite, bezieht sich friend einschließlich auf die Klasse in welcher es angwendet wird, wenn ich internal anwende, bezieht es sich auf meine ganze Assembly und es wurde schon in vorherigen Posts korrekt erkkannt wie ich es machen möchte.

NoAir schrieb:
Hallo,

"internal" geht nur, wenn er zwei Assemblys hat (.dll + .exe).
Hat er nur eine (.exe) ist "internal" mit "public" gleichgestellt und somit komplett fürn Eimer.

Grüße

P.S. Will er eine Lib entwickeln, stellt sich dieses Problem natürlich erst gar nicht. Ich denke jedoch, dass er die 3 Klassen in seinem Projekt benutzen möchte?!

Und friend und internal zeigen in meinen Augen überhaupt nicht das Ergebnis was ich erwarte.Aber anscheint funktioniert es einfach nicht so Trotzdem danke für die Antworten.

[hajb]

jo.

Ich verstehe das so: Dummy soll seinen Zustand verbergen. Vermutlich eine gute Idee. Aber der Zustand ist nicht konstant, denn Actors (und ggf. andere) sollen ja den Zustand ändern können, nur eben nicht beliebig. Dann lass den Dummy das doch selbst machen! Dein Pattern heißt "Methode". Wenn nur bestimmte Dinge nicht gemacht werden dürfen (zb. negative Werte), dann kannst du auch eine Property nehmen und den Wert vor der Zuweisung prüfen.

class Dummy
{
	private int wichtigevariable;

	public Dumm()
	{
		//...
	}
	//readonly property wird man vielleicht auch mal brauchen
	public int WichtigeVariable { get { return wichtigevariable; } }

	public void TuWas()
	{
		//TODO: Add logic here 
		// e.g.:
 		++wichtigevariable;
	}
}
class Holder
{
	private readonly Dummy dummy;
	public Dummy{ get { return dummy; } }

	public Holder(Dummy dumm)
	{
		dummy=dumm;
		//...was mit dem Dummy
	}
}
class Acter
{
	private Dictionary<int,Holder> dummys;

	public Acter()
 	{
		//....
	}
	public void erhoehen(/*irgendwelche parameter*/)
	{
		foreach(Holder holder in dummys)
		{
			//TODO: Add more logic here
			holder.Dummy.TuWas();
			//TODO: And here
		}
	}
}

Grantopalen.

[Firefighter]

Hmm das wäre eine Möglichkeit.Danke dir für die ausführliche Antwort.

[SolidOffline]

Ok, ich geb's auf. Evtl. einfach mal nach "c# internal friend" googeln, vielleicht fällt dann der Cent.

<bitte hier Picard vorstellen, der resignierend den Kopf in seiner Hand verbirgt>