Code in Methode auslagern möglich?

[player_z]

Hallo zusammen,
ich habe folgendes Problem.
Ich habe eine switch-case abfrage mit 6 verschiedenen case-Fällen. Diese Fälle sind jeweils ewig lang, enthalten aber bis auf wenige Zeilen, immer den selben Code. Diese Zeilen sind Methodenaufrufe. In Case-Fall 1 wird die Methode m1 aufgerufen, in case-Fall 1 die Methode m2()

Besteht die Möglichkeit eine Methode zu erstellen, die jeweils den Methodennamen mitgegeben bekommt?
Also etwa so
switch()
case 0:einemethode(m1());
break;
case 1:einemethode(m2());
break;

Vielen Dank im Voraus.

 

[Gast2]

Würde über Reflections gehen, aber das solltest du nicht machen.

Alles was gleich ist schreibst du einfach vor die switch anweisung (auch gerne in methodenaufrufe ausgelagert), da wo es sich unterscheidet schreibste dann nen switch.

 

[Reflections]

Einen Methoden-Namen kannst du nur verwenden wenn du mit Reflections arbeitest.
Aber warum machst du es nicht anders : wenn deine 6 Calls immer quasi den selben Code enthalten dann nimm doch nur eine und füge genau an der Stelle wo die Codes unterschiedlich sind das switch-case ein. Denn wenn du 6 Methoden machst in denen sich dann nur 2 oder 3 Zeilen unterscheiden nennt sich das "Code-Duplizierung" und das sollte immer möglichst vermieden werden.
Aber einfach eine "machWas()" Methode schreiben und dieser einen anderen Methoden-Namen übergeben geht so nicht. Dafür gibt es via Reflections die Möglichkeit [japi]Class#getDeclaredMethod(java.lang.String, java.lang.Class...)[/japi] und zu deren Ausführung [japi]Method#invoke(java.lang.Object, java.lang.Object...)[/japi].

Aber für deine Aufgabe sollte man keine Reflections verwenden. Eher so wie EikeB und ich angemerkt haben.

 

[player_z]

problem ist, dass ich die methoden mehrmals aufrufe, also am ende, in der mitte, aber auch ganz am anfang, dann bringts auch nix das vor die switch anweisung zu schreiben

 

[HoaX]

Klingt dann ehr nach einem Fehler im Konzept. Wenn du genauer erläuterst was das für Methoden sind und wie diese Zusammenhängen mit dem Switch, evtl. mit etwas Code, dann kann man bestimmt Tipps geben wie man es anders/besser machen kann.

 

[player_z]

so sieht das aus:

switch (tmp) {
			
			case 1:
				geklappt = setLinks(a);
				while (!geklappt) {
					if (a.isGespiegelt() && a.getDrehung() == 3) {
						a.print();
						System.out.println("Passt nicht auf diese Seite");
						a.setGespiegelt(false);
						cntlinks++;
						liste.add(a);
						a.setVerwendet(false);
						if (cntlinks == liste.size()) {
							if (vorne.isGespiegelt() && vorne.getDrehung() == 3) {
								liste.add(vorne);
								vorne.setGespiegelt(false);
								cntlinks = 0;
							} else {
								vorne.drehen();
								liste.addFirst(vorne);
							}
							links = new Seite();
							vorne.setVerwendet(false);
							tmp--;
							cntlinks = 0;
						}
						break;
					}
					a.drehen();
					geklappt = setLinks(a);
				}
				if (geklappt) {
					a.print();
					System.out.println("passt links");
					tmp++;
				}
				break;
			case 2:
				geklappt = setHinten(a);
				while (!geklappt) {
					if (a.isGespiegelt() && a.getDrehung() == 3) {
						a.print();
						System.out.println("Passt nicht auf diese Seite");
						a.setGespiegelt(false);
						cnthinten++;
						liste.add(a);
						a.setVerwendet(false);
						if (cnthinten == liste.size()) {
							if (links.isGespiegelt() && links.getDrehung() == 3) {
								liste.add(links);
								links.setGespiegelt(false);
								cnthinten = 0;
							} else {
								links.drehen();
								liste.addFirst(links);
							}
							hinten = new Seite();
							links.setVerwendet(false);
							tmp--;
							cnthinten = 0;
						}
						break;
					}
					a.drehen();
					geklappt = setHinten(a);
				}
				if (geklappt) {
					a.print();
					System.out.println("passt hinten");
					tmp++;
				}
				break;
			case 3:

 

[HimBromBeere]

Unabhängig von deiner Frage kann ich dir zumindest schonmal sagen, dass die Bedingung in Zeile 32 obsolet ist, denn die vorherige while-Schleife wird sowieso nur für den Fall beendet, dass

geklappt

auf wahr steht.

 

[Marco13]

Als es noch keine elektronischen Hilfsmittel dafür gab, benutzte man zur Kartographierung des Sternenhimmels und insbesondere zur Identifikation von bewegten Objekten (Kometen) ein spezielles Gerät: Dort konnten zwei Bilder eines Himmelsausschnitts eingespannt werden, die zu unterschiedlichen Zeiten gemacht wurden. Man konnte in dieses Gerät reinsehen, und mit einem Kippmechanismus schnell zwischen den eingelegten Bildern hin- und her schalten. Objekte, die sich bewegt hatten nahm man als "blinkend" wahr. Das Menschliche Auge reagiert erstaunlich empfindlich auf Änderungen, wie etwa ein Blinken.

Gelegentlich füge ich zwei Codestücke als zwei Dokumente in TextPad ein, und schalte dann mit den Pfeiltasten hoch und runter, zwischen den Dokumenten hin und her. Die unterschiedlichen Teile des Codes blinken dann vor sich hin.

(Es gab Leute, die mich erstaunlich oft dazu genötigt haben, indem sie sich einen neuen Job suchten, und mir :autsch: Code hinterließen)

Womit wir bei deinem Code wären

Im wesentlichen müsste ja anscheinend die Methode "setHinten" bzw. "setLinks" rausfaktorisiert werden. Ohne auf die anderen möglichen Details einzugehen, die im nicht-geposteten Code stecken:

interface ThingSetter{
    boolean setThing(Thing t);
}

void machWasKrampfigAussehendesMit(ThingSetter ts)
{
                geklappt = ts.setThing(a);
                while (!geklappt) {
...
                    geklappt = ts.setThing(a);
                }
...
}

// Aufruf:
ThingSetter hintenSetter = new ThingSetter() {
    @Override
    public boolean setThing(Thing t) { return setHinten(t); }
}
machWasKrampfigAussehendesMit(hintenSetter);
...
machWasKrampfigAussehendesMit(vorneSetter);
machWasKrampfigAussehendesMit(schrägDiametralGegenüberSetter);
...

 

[JohannisderKaeufer]

Misko Hevery hat vor ein paar Jahren einen, wie ich finde recht guten Vortrag gehalten.

Dort beschreibt er, wie man von if's und switch-Statements zu einem Objektorientierten Ansatz kommt und wo die Vorteile dabei liegen.

"The Clean Code Talks -- Inheritance, Polymorphism, & Testing" - YouTube

 

[ARadauer]

im Grunde das was dein Code macht in kleine schlanke Methoden auslagern... wenn du sagst

Diese Fälle sind jeweils ewig lang, enthalten aber bis auf wenige Zeilen, immer den selben Code

dieser gleiche Code macht ja was bestimmtes, also auslagern und wiederverwenden..