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
Wieso nicht einfach ein Enum der Modi anlegen und in den Methoden prüfen ob sich das Programm im vorausgesetzten Modus befindet?
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));}}
Aber je nach Modus, in dem sich das Programm befindet, dürfen nicht alle zugänglich sein.
Was heißt "Modus" in deinem Fall?
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!"
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
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?
...?
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.
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
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...
@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. 😉
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
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
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...
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
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