Ich habe eine Klasse geschrieben in der eine Datei ausgelesen wird und die gelesenen Werte in über 20 public string Variablen geschrieben werden. Jede Variable hat ihren eingenen Namen, ein Array ist nicht vorhanden. Diese Variablen stelle ich nun in einer Form in Textboxen dar. Wie kann man sowas besser lösen? Weil alles public zu machen, entspricht ja nicht gerade der OOP. Ich habe mir folgendes ausgedacht: public string funktion(int nr) { switch(nr) { case 0: return Variable_A; break; case 1: return Variable_B; break; // usw. } }
Du hast also Member-Variablen in einer Klasse, die als private deklariert sind. Dann hast Du Methoden der Klasse, die von außerhalb ein Lesen der Variablen erlauben (auch "getter" genannt). Willkommen in der OOP :-)
Gast schrieb: > Wie kann man sowas besser lösen? Weil alles public zu machen, entspricht > ja nicht gerade der OOP. > > Ich habe mir folgendes ausgedacht: > > public string funktion(int nr) > { > switch(nr) > { > case 0: > return Variable_A; > break; > > case 1: > return Variable_B; > break; > > // usw. > } > } Kann man natürlich machen. Die Frage lautet allerdings: Was ist mit diesen 20 Strings? Was ist daran so speziell, dass du sie nicht in ein Array stellst und die einzelnen Variablen rauswirfst. Ist ein Array überhaupt zweckdienlich, oder kann man die 20 Strings wieder in anderer Form sonnvoll zusammenfassen. Zb Vorname + Nachname in eine Klasse Name packen. Oder Postleitzahl, Wohnort, Strasse, Hausnummer zu einer Klasse Adresse zusammenfassen. Wenn es allerdings überhaupt keinen Zusammenhang der 20 Strings gibt, warum muss dann alles über eine einzige Zugriffsfunktion abgehandelt werden. Da muss ich mir dann ja erst recht wieder merken, welcher String der String mit der Nummer 9 ist.
Karl heinz Buchegger schrieb: > werden. Da muss ich mir dann ja erst recht wieder merken, welcher > String der String mit der Nummer 9 ist.
1 | public string funktion(char var) |
2 | {
|
3 | switch(var) |
4 | {
|
5 | case 'A': |
6 | return Variable_A; |
7 | break; |
8 | |
9 | case 'B': |
10 | return Variable_B; |
11 | break; |
12 | |
13 | // usw.
|
14 | case 'T': |
15 | return Variable_T; |
16 | break; |
17 | |
18 | // usw.
|
19 | }
|
20 | }
|
Dan mußt du dir keine Nummern merken ;) > Weil alles public zu machen, entspricht > ja nicht gerade der OOP. Aha... warum den nicht? Wenn du willst das jeder zu jederzeit uneingeschränkt die Variablen nutzen und verändern könne darf wieso nicht. OO heißt doch nicht das es getter/setter gibt...
An und Pfirsich sollte man so viel wie nötig public deklarieren, aber so wenig wie möglich. Wenn ich immer alles public mache, kann ich ja gleich eine struct nehmen anstatt einer Klasse ;-)
Wenn du alles anzeigen willst -> Reflection ist das Stichwort
Hier noch Beispielcode für eine dynamische Variante. Die Werte und Bezeichner der Variablen werden in einem Dictionary abgelegt. Der Zugriff erfolgt über eine indexed property.
1 | private readonly Dictionary<string, string> VarDict = new Dictionary<string, string>(); |
2 | |
3 | private void LeseDatei() |
4 | {
|
5 | ...
|
6 | |
7 | InitVar("NameVariableA", Variable_A); |
8 | InitVar("NameVariableB", Variable_B); |
9 | InitVar("NameVariableC", Variable_C); |
10 | |
11 | ...
|
12 | |
13 | }
|
14 | |
15 | private void InitVar(string varName, string varValue) |
16 | {
|
17 | VarDict.Add(varName, varValue); |
18 | }
|
19 | |
20 | public string this[string varName] |
21 | {
|
22 | get
|
23 | {
|
24 | string varVal; |
25 | if( VarDict.TryGetValue(varName, out varVal) ) |
26 | {
|
27 | return varVal; |
28 | }
|
29 | |
30 | return string.Empty; |
31 | }
|
32 | }
|
In C# sind für den Zugriff auf die internen Felder Properties vorgesehen:
1 | public class Abc { |
2 | ...
|
3 | private string _myData; |
4 | public string MyData |
5 | {
|
6 | set { _myData = value; } |
7 | get { return _myData; } |
8 | }
|
9 | ...
|
10 | }
|
11 | |
12 | public class Xyz { |
13 | ...
|
14 | void DoSomething() |
15 | {
|
16 | MyData dObj = new MyData(); |
17 | string data = dObj.MyData; |
18 | ...
|
19 | dObj.MyData = "foo"; |
20 | }
|
21 | ...
|
22 | }
|
Der oben erwähnte Ansatz mit einer Zugriffs-Methode mit "Property-Identifikation" (funktion(int nr)) würde man unter C# (.NET) üblicherweise nicht über switch-case, sondern mit Hilfe eines generischen Dictionary<keyTyp,valueTyp> erledigen. Das Verfahren hat allerdings einen einen gewaltigen Nachteil (unabhängig von der Implementierung über switch-case oder Dictionary): Der Compiler kann nicht bestimmen, ob ein Property existiert oder nicht. Diese Fehler treten erst zur Laufzeit (also beim Kunden) auf. Aus diesem Grund implementiert man eben 20 String-Properties, wenn diese tatsächlich voneinander unabhängig sind. Irgendwelche Zuriffe auf nicht existierende Properties findet dann bereits der Compiler. Oder man überlegt sich ein besser passenderes Modell. Markus
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.