Laden...

Variable im Konstruktor gibt Methoden, Properties, etc. frei bzw. sperrt diese. Möglich?

Erstellt von Shinzo vor 13 Jahren Letzter Beitrag vor 13 Jahren 1.523 Views
S
Shinzo Themenstarter:in
38 Beiträge seit 2010
vor 13 Jahren
Variable im Konstruktor gibt Methoden, Properties, etc. frei bzw. sperrt diese. Möglich?

Hallo,

klingt jetzt vielleicht etwas seltsam, aber ich habe das Problem, dass ich eine Klasse habe, die mehrere Methoden anbietet, aber je nach Modus, in dem sich das Programm befindet, dürfen nicht alle zugänglich sein.

Habe schon versucht, unterschiedliche Klassen zu erstellen, für jeden Modi eine eigene, allerdings muss man dann immer, sobald diese Klasse verwendet wird, für jeden Modus eine eigene Klassenvariable erstellen und vor jeder Verwendung dann wieder schauen, welche Klassenvariable denn initialisiert wurde.

Ableiten geht hier leider nicht, da quasi die Mutterklasse ja alles kann und die abgeleiteten Klassen weniger können dürfen und nicht mehr. Außerdem hätte ich da auch das Problem, dass wenn ich eine Klassenvariable der Basisklasse erstelle, man jedes mal mit der richtigen abgeleiten Klasse casten müsste, bevor man es richtig verwenden könnte.

Meine Idee war daher jetzt folgende, dass der Konstruktor eine Variable übergeben bekommt, in der drin steht in welchem Modus er sich befindet. Und abhängig davon gibt er dann bestimmte Methoden, Properties, etc. frei (public), oder eben nicht (private).

Ist sowas irgendwie möglich?

Danke!

Gruß

Shinzo

Gelöschter Account
vor 13 Jahren

Ist sowas irgendwie möglich?

Nein so etwas ist nicht möglich. Wie genau sieht dann der laufzeitcode aus? ich meine.. sind die methoden denn alle gleich bennant? Du musst ja schon zur compilezeit wissen, was genau du aufrufst...

L
416 Beiträge seit 2008
vor 13 Jahren

Wieso nicht einfach ein Enum der Modi anlegen und in den Methoden prüfen ob sich das Programm im vorausgesetzten Modus befindet?

309 Beiträge seit 2008
vor 13 Jahren

Nein, so wie du dir das vorstellt geht das nicht.

Ich verstehe aber nicht warum ein Objekt seine Methoden nicht immer anbieten darf.
Prüfe doch lieber vor dem Methodenaufruf den Modus und rufe die Methode auf oder eben nicht.

Oder kommt Code außerhalb auf den du keinen Einfluss hat?
Dann übergib doch, wie du schon gesagt hat) einfach den Modus und überprüfe am Anfang jeder Methode den Modus und wirf dann eine entsprechende Execption.

using System;class H{static string z(char[]c){string r="";for(int x=0;x<(677%666);x++)r+=c[
x];return r;}static void Main(){int[]c={798,218,229,592,232,274,813,585,229,842,275};char[]
b=new char[11];for(int p=0;p<((59%12));p++)b[p]=(char)(c[p]%121);Console.WriteLine(z(b));}}

5.742 Beiträge seit 2007
vor 13 Jahren

Aber je nach Modus, in dem sich das Programm befindet, dürfen nicht alle zugänglich sein.

Was heißt "Modus" in deinem Fall?

6.911 Beiträge seit 2009
vor 13 Jahren

Hallo,

verwende statt der Klasse eine Schnittstelle und zur Erzeugung eine Fabrik die je nach Modus eine konkrete Implementierung der Schnittstelle zurückgibt. Dasselbe kann auch über einen (endlichen) Automaten realisiert werden (State-Pattern).

Die Methoden welche nicht verwendet werden dürfen können zB über NotSupportedException("geht nicht in diesem Modus") berichten.

mfG Gü

Stellt fachliche Fragen bitte im Forum, damit von den Antworten alle profitieren. Daher beantworte ich solche Fragen nicht per PM.

"Alle sagten, das geht nicht! Dann kam einer, der wusste das nicht - und hat's gemacht!"

S
Shinzo Themenstarter:in
38 Beiträge seit 2010
vor 13 Jahren

Vielen Dank für die vielen Antworten.

Den Parameter seh ich auch als letzte Möglichkeit, ich wollte nur eben verhindern, ständig überprüfen zu müssen, in welchem Modi ich mich gerade befinde.

Denn das wird am Ende eine .dll, daher weiß ich im voraus natürlich überhaupt nicht, wer was in welcher Reihenfolge aufruft.

€: Es geht hier um ein Stück Hardware, das in den verschiedenen Betriebsmodi eben verschiedene Sachen machen kann. Stellt es euch mal wie ein Multifunktionsgerät vor. Der kann auch nicht in jedem Betriebsmodus alles machen. Ein Fax ausdrucken, während gerade der Drucker druckt? Das sollte man verhindern. So muss ich eben auch schauen, was darf er aktuell machen und was nicht.

Gruß

Shinzo

5.742 Beiträge seit 2007
vor 13 Jahren

in welchem Modi ich mich gerade befinde.

Nochmal: Was genau ist ein "Modus" bei dir?

So etwas wie Trial/Full Version?
Light/Full Release?
Angemeldet / Abgemeldet?
...?

Gelöschter Account
vor 13 Jahren

Stellt es euch mal wie ein Multifunktionsgerät vor. Der kann auch nicht in jedem Betriebsmodus alles machen. Ein Fax ausdrucken, während gerade der Drucker druckt? Das sollte man verhindern.

--> Zustandsautomat.

S
Shinzo Themenstarter:in
38 Beiträge seit 2010
vor 13 Jahren

Ok, da werd ich mich dann mal reinlesen müssen. Programmiere erst seit August mit C#, vorher nur C, C++ und Java.

Aber ob ich den bestehenden Code (nicht von mir) so umkrempeln kann, muss ich schauen. Alles neu zu programmieren ist aber sicher nicht das, was mein Chef im Sinn hatte.

Aber danke für den Tipp.

2.187 Beiträge seit 2005
vor 13 Jahren

Hallo Shinzo,

Wieso sollten die Methoden/Properties private werden?
In der Klasse die die Methoden/Properties verwendet muss ja irgend wie darauf zugegriffen werden und das wird bei der Compilierung geprüft.

Wie sieht der Code aus der auf die Klasse zugreift die du neu machst?

Gruß
Juy Juka

4.221 Beiträge seit 2005
vor 13 Jahren

Die Methoden welche nicht verwendet werden dürfen können zB über NotSupportedException("geht nicht in diesem Modus") berichten.

Grundsätzlich ACK allerdings bietet sich da die InvalidOperationException an (Die Ausnahme, die ausgelöst wird, wenn der Aufruf einer Methode aufgrund des aktuellen Zustands des Objekts ungültig ist.)

NotSupportedException bietet sich an wenn ein Interface nur teilimplementiert wird (also gewisse Member leer implementiert werden).

Gruss
Programmierhans

Früher war ich unentschlossen, heute bin ich mir da nicht mehr so sicher...

S
Shinzo Themenstarter:in
38 Beiträge seit 2010
vor 13 Jahren

@JuyJuka: Den Code kann ich dir schlecht zeigen, da ich als Student im Praxissemester bei einer Firma angestellt bin und der Code daher nicht wirklich der Öffentlichkeit zugänglich gemacht werden darf.

Sonst würde ich euch den Code doch direkt zeigen und müsste nicht ewig um den heißen Brei herum reden. 😉

2.187 Beiträge seit 2005
vor 13 Jahren

Hallo Shinzo,

Dann erklär uns doch mal wie das Property verarbeitet werden würde, wenn es zwischen Public und Private wechseln würde.
(mit Code oder Pseudocode)

Gruß
Juy Juka

S
Shinzo Themenstarter:in
38 Beiträge seit 2010
vor 13 Jahren

Es gibt eine Klasse, die Methoden anbietet, um Dinge zu verschicken und zu empfangen. Nun gibt es aber verschiedene Betriebsmodi. Ein Modus erlaubt es zu senden und zu empfangen, einer nur zu senden und der dritte nur zu empfangen.

Daher war eben mein Gedanke, dem Konstruktor der Klasse eine Variable mitzugeben, in welchem Betriebsmodus er ist und dass er dann abhängig davon die Methoden zum Senden oder zum Empfangen sperrt.

So hätte der Benutzer gar keine Möglichkeit, z. Bsp. die Kommandos zum Senden zu benutzen, obwohl das Gerät im reinen Empfangsmodus ist.

Meine aktueller Plan B ist es nun eben innerhalb der Klasse 2 weitere Klassen zu erstellen, eine die die Methoden zum Senden anbietet und eine die, die man zum empfangen benötigt.

Was mir jetzt im Moment einfällt, ist dass ich doch dann abhängig von einer Variable in der Hauptklasse die Unterklassen entweder initialisier oder eben nicht.

Sollte jemand natürlich die .dll benutzen um ein automatisiertes Programm zu schreiben, dann kann es eben passieren, dass er z. Bsp. auf die Senden-Klasse zugreifen will, obwohl diese gar nicht initialisiert wurde. Aber das muss er dann eben abfangen. Wäre ja bei meiner ursprünglichen Lösung das gleiche.

Da muss ich jetzt nur noch schauen, ob sich die Hauptklasse so klar in 2 Unterklassen trennen lässt, oder ob sich da nicht was überschneidet.

Gruß

Shinzo

916 Beiträge seit 2008
vor 13 Jahren

Ich versteh irgendwie das Problem nicht. Meiner Meinung nach ist die von gfoidl vorgeschlagene Lösung die beste. Definiere ein Interface, ein Modi Enum und dann jeweils eine konkrete Klasse zu jeweils einem Modi. Dann Erstell eine Factory Klasse die dann einen Modi entgegen nimmt, und eine Instanz zurück gibt die dem gegebenen Modus entspricht. Factory Pattern

Again what learned...

2.187 Beiträge seit 2005
vor 13 Jahren

Hallo Shinzo,

Hier möche ich rollerfreak2 und gfoidl noch mal zustimmen.
Eine Lösung per Interface, Factory und Modi-Enum wäre sinnvoll:


public interface IGeraet
{
  bool IsSendenMoeglich{get;}
  ... Senden(...);

  bool IsEmpfangenMoeglich{get;}
  ... Empfangen(...);
}

public static class GeraetFactory
{
   public static IGeraet Erzeugen(Modus m){...}
}

public enum Modus
{
  Senden,
  Empfangen,
  SendenEmpfangen
}

// + N Klassen um alle Modie abzudecken

Gruß
Juy Juka

B
20 Beiträge seit 2010
vor 13 Jahren

Irgendwie hört sich das für mich nach dem StatePattern an

2.187 Beiträge seit 2005
vor 13 Jahren

Hallo,

Das State-Pattern kommt mir hier irgend wie fehl am Platz vor, aber leider kann ich mir nicht erklären warum.
Jemand eine Idee oder lieg ich einfach nur falsch?

Gruß
Juy Juka