Wie kommentiert ihr?

[SideWinder]

-fricky- schrieb:

SideWinder schrieb:

Gibt verschiedene Möglichkeiten, zB:
methods[case].invoke();

das fängt nicht den default-fall ab. ausserdem erzeugen compiler für sitch/case-konstrukte sehr effizienten code, was bei einer tabelle mit function-pointern nicht immer gegeben ist. also ich finde es nie gut, performance gegen 'schönen code' zu tauschen.

Ich würde immer Performance gegen "schönen Code" tauschen. Aber abgesehen davon, habe ich nicht behauptet, dass mein Code "schön" ist. Es war nur ein Beispiel. Das kommt dann immer auf das konkrete Beispiel an. Aber Dinge wie:

switch(errorcode)
{
    case 404: return NLS.get("DOC_NOT_FOUND"); break;
    ... // weitere 1000 fälle
}

rgen mich ganz furchtbar auf:

String str = NLS.get(errorMap.get(404));

MfG SideWinder

[SideWinder]

Wobei, wenn man tatsächlich mehr als 5 "Modi" hat die alle differenten Quellcode zur Ausführung bringen und die wirklich (meistens Designschwäche) durch das selbe switch abgedeckt werden sollen, würde ich schon auf dynamischen Methodenaufruf setzen (da brauch ich dann auch keinen default-Fall, denn default-mäßig ruft mein Benutzer nicht den Punkt File->Open auf ... im Notfall kommt eine NotFoundException und auf die kann ich dann reagieren).

MfG SideWinder

[-fricky-]

byto schrieb:

Polymorphie nutzen.

ich wusste doch, dass es noch sinnvolle anwendungen von OOP gibt.

SideWinder schrieb:

Wobei, wenn man tatsächlich mehr als 5 "Modi" hat die alle differenten Quellcode zur Ausführung bringen und die wirklich (meistens Designschwäche) durch das selbe switch abgedeckt werden sollen, würde ich schon auf dynamischen Methodenaufruf setzen.

die designschwächen machen aber oft andere (siehe dein beispiel mit dem http) und damit muss man leider leben.

SideWinder schrieb:

im Notfall kommt eine NotFoundException und auf die kann ich dann reagieren).

das halte ich wiederum für schlechten stil: exceptions einzusetzen, obwohl man mit einem einfachen 'if' testen kann, ob ein wert überhaupt gültig ist.

[tfa]

Bashar schrieb:

byto schrieb:

Polymorphie nutzen.

Gratulation, du hast gerade eine Funktion zu 30 vom Designstandpunkt her völlig überflüssigen Klassen vereinfacht.

Woher willst du das wissen? Vielleicht hat er auch unwartbaren Spaghetticode zu einem vernünftigen OO-Design gemacht.

[SideWinder]

@fricky: Naja, grundsätzlich kann der Benutzer keine nicht vorhandenen Menüpunkte aufrufen. Also handelt es sich in so einem Fall imho sehrwohl um eine Exception.

Edit: Ja, damit muss man wohl leben. Aber man muss diese Schwächen (warum auch immer die hier sind - gibt es eine bessere Methode?) nicht auch noch mit schwachem Code in das eigene Projekt hineinziehen.

MfG SideWinder

[-fricky-]

SideWinder schrieb:

@fricky: Naja, grundsätzlich kann der Benutzer keine nicht vorhandenen Menüpunkte aufrufen. Also handelt es sich in so einem Fall imho sehrwohl um eine Exception.

nichtvorhandene menüpunkte triggern keine aktionen, also können auch keine exceptions auftreten. aber ich glaube, so langesam reden wir aneinander vorbei.

[Bashar]

tfa schrieb:

Bashar schrieb:

byto schrieb:

Polymorphie nutzen.

Gratulation, du hast gerade eine Funktion zu 30 vom Designstandpunkt her völlig überflüssigen Klassen vereinfacht.

Woher willst du das wissen? Vielleicht hat er auch unwartbaren Spaghetticode zu einem vernünftigen OO-Design gemacht.

Da er nicht mehr Informationen hat, als dass da eine Funktion ein längliches Switch enthält, ist das unwahrscheinlich. Reflexartig irgendwelche Patentrezepte auf nichtexistente Probleme anzuwenden ist eigentlich eher das, was unwartbare Designs erst erzeugt.

[tfa]

Bashar schrieb:

Da er nicht mehr Informationen hat, als dass da eine Funktion ein längliches Switch enthält, ist das unwahrscheinlich.

Und aus diesen wenigen Informationen kannst du ableiten, dass OO hier böse ist und er lieber ein Spaghetti-Switch machen soll? Respekt! Ich trau mir das nicht zu.

Hast du schonmal was vom State Pattern gehört? Wer es nicht kennt läuft Gefahr, das eine oder andere überflüsse switch in seinen Code einzubauen, statt ein wartbares Entwurfsmuster zu verwenden. Das soll natürlich nicht heißen, dass switch völlig überflüssig und immer zu ersetzen ist. Aber nachdenken sollte man schon drüber.

Bashar schrieb:

Reflexartig irgendwelche Patentrezepte auf nichtexistente Probleme anzuwenden ist eigentlich eher das, was unwartbare Designs erst erzeugt.

Ich finde reflexarte Ablehnung von OO-Mustern viel gefährlicher. Außerdem würde ich ein überlanges switch nicht als "nichtexistentes" Problem ansehen.

[DEvent]

byto schrieb:

Nicht mehr dokumentieren als zum groben Verständnis nötig. Schließlich muss man die Doku beim Code-Refactoring immer mitpflegen. Je kürzer die Dokumentation, umso leichter fällt das. Je leichter es fällt, umso häufiger wirds gemacht.

Und nichts ist schlimmer, als eine veraltete (falsche) Dokumentation. Die ist dann nämlich schlechter als gar keine Doku weil irreführend!

Der einzige Fall in dem du die Dokumentation aendern musst, ist es, wenn du das Interface der Methode veraenderst.

Wie loks richtig gesagt hat, soll die Dokumentation aussagen was die Methode machen soll. Wie sie es macht, kann sich sicher oft aendern.

[*john 0]

-fricky- schrieb:

also ich finde es nie gut, performance gegen 'schönen code' zu tauschen.

Das sind Mikrooptimierungen, die nur als Ausrede für schlechten Code verwendet werden. Select-Orgien werden in massenweise bedingte Sprünge übersetzt und die bringen die spekulative Ausführung der CPU ziemlich durcheinander. Wann welcher Code schneller ist hängt auch von den Cache-Größen, wie oft der Code durchlaufen wird ab etc. pp.

Ohne Profiling einfach so zu postulieren Code A sei schneller als Code B halte ich zumindest für gewagt. Ein sauberes Design ist aus Gründen der Wartbarkeit vorzuziehen, und nur im Falle von nicht ausreichender Performance ist darauf zu verzichten.

[Gast]

Ohne zu wissen auf welchem Target, welchem Umfeld, welcher Sprache etc. man sich bewegt _irgendwas_ zu postulieren ist... ach ich halt mich raus. 13 Wahrheiten reichen fürs erste...

[Blue-Tiger]

-fricky- schrieb:

Also ich finde es nie gut, performance gegen 'schönen code' zu tauschen.

o_0 Ernsthaft? Dann schreibst du also nur Performance-Kritische Anwendungen, die auf 8-Bit-Microprozessoren ausfuehren sind und starke Echtzeitbedingungen stellen. Falls dem nicht so ist: bitte erklaer warum du das findest Schoener Code ist leichter wartbar/lesbar/verstehbar (und damit vermutlich irgendwann auch bugfreier). Auf heutigen X Ghx-Prozessoren mit X GB RAM kommts auf virtuelle Methodenaufrufe statt switches einfach so gut wie nie an.

Uebrigens kommen wir stark vom Thema ab. Mal eine Frage an die "Vieldokumentierer", die auch getSize dokumentieren: dokumentiert ihr auch alle private-Variablen?

[Bashar]

tfa schrieb:

Bashar schrieb:

Da er nicht mehr Informationen hat, als dass da eine Funktion ein längliches Switch enthält, ist das unwahrscheinlich.

Und aus diesen wenigen Informationen kannst du ableiten, dass OO hier böse ist und er lieber ein Spaghetti-Switch machen soll? Respekt! Ich trau mir das nicht zu.

Nochmal für dich zum mitmeißeln: Das switch besteht schon, der Vorschlag war, es zu beseitigen, indem man "Polymorphie anwendet". Es steht nicht zur Debatte, für ein vorliegendes Problem zwischen den Designalternativen switch und "OO" zu entscheiden.
BTW was soll ein "Spaghetti"-Switch sein? Von Spaghetti-Code spricht man bei verschlungenem, nicht nachvollziehbarem Kontrollfluss. Dazu eignet sich wilder goto-Einsatz besonders gut. Wer den Kontrollfluss eines switch-Statements nicht nachvollziehen kann, sollte m.E. den Beruf wechseln.

Hast du schonmal was vom State Pattern gehört? Wer es nicht kennt läuft Gefahr, das eine oder andere überflüsse switch in seinen Code einzubauen, statt ein wartbares Entwurfsmuster zu verwenden. Das soll natürlich nicht heißen, dass switch völlig überflüssig und immer zu ersetzen ist. Aber nachdenken sollte man schon drüber.

Was willst du mir damit sagen? Dass das State-Pattern dazu da ist, switches zu ersetzen? Das kann ja wohl nicht dein Ernst sein. Oder dass man switch durch State ersetzen sollte?

Bashar schrieb:

Reflexartig irgendwelche Patentrezepte auf nichtexistente Probleme anzuwenden ist eigentlich eher das, was unwartbare Designs erst erzeugt.

Ich finde reflexarte Ablehnung von OO-Mustern viel gefährlicher. Außerdem würde ich ein überlanges switch nicht als "nichtexistentes" Problem ansehen.

Jetzt fang nicht an mir irgendwas zu unterstellen, was ich nicht gesagt habe. Was das Problem an einem switch sein soll hast du immernoch nicht gesagt.

[tfa]

Bashar schrieb:

[...]
BTW was soll ein "Spaghetti"-Switch sein? Von Spaghetti-Code spricht man bei verschlungenem, nicht nachvollziehbarem Kontrollfluss. Dazu eignet sich wilder goto-Einsatz besonders gut. Wer den Kontrollfluss eines switch-Statements nicht nachvollziehen kann, sollte m.E. den Beruf wechseln.
[...]
Was willst du mir damit sagen? Dass das State-Pattern dazu da ist, switches zu ersetzen? Das kann ja wohl nicht dein Ernst sein. Oder dass man switch durch State ersetzen sollte?
[...] Was das Problem an einem switch sein soll hast du immernoch nicht gesagt.

Am besten liest du diesen Thread nochmal durch, besonders, was ich geschrieben habe. Dann klickt du auf den State-Pattern-Link und liest dir das durch. Aber auch ganz nach unten scrollen (wichtig)!
Vielleicht wird's dann Licht. Nimm dir ruhig soviel Zeit wie du brauchst.

[Bashar]

tfa schrieb:

Am besten liest du diesen Thread nochmal durch, besonders, was ich geschrieben habe.

Soviel war das ja nicht.

Dann klickt du auf den State-Pattern-Link und liest dir das durch. Aber auch ganz nach unten scrollen (wichtig)!
Vielleicht wird's dann Licht. Nimm dir ruhig soviel Zeit wie du brauchst.

Wie man Arroganz stilvoll anbringt musst du aber noch lernen.

[Rolf Imo]

Bashar einfach davon auszugehen, dass irgendein switch mit 30 cases optimal ist und deinem Fall entspricht ist schon extrem unrealistisch.

[byto]

Bashar schrieb:

Nochmal für dich zum mitmeißeln: Das switch besteht schon, der Vorschlag war, es zu beseitigen, indem man "Polymorphie anwendet". Es steht nicht zur Debatte, für ein vorliegendes Problem zwischen den Designalternativen switch und "OO" zu entscheiden.

So hab ich das nie geschrieben oder gemeint. Vielmehr ist in den meisten Fällen schon einiges schief gelaufen, wenn Du überhaupt an den Punkt kommst, ein Switch mit 30 Cases am Stück zu schreiben. Wenn Du konsequent objektorientiert strukturierst, wirst Du in den meisten Fällen gar nicht erst in diese Verlegenheit kommen, solche Monolithen zu implementieren.

Natürlich mag es auch (seltene) Fälle geben, wo man nicht drum herum kommt. Aber auch da ist ein 30er Switch imo eher die schlechtere Wahl. Da wird es sich wohl meistens eher anbieten, diesen Monolith aufzubrechen und z.B. als Chain of Responsibility (siehe GOF) zu implementieren.

Naja, aber wahrscheinlich irre ich, die GOF und alle anderen und Du hast Recht.

SWITCH++

[tfa]

Bashar schrieb:

tfa schrieb:

Am besten liest du diesen Thread nochmal durch, besonders, was ich geschrieben habe.

Soviel war das ja nicht.

OK, hier kommt der Vorlese-Service:

tfa schrieb:

Vielleicht hat er auch unwartbaren Spaghetticode zu einem vernünftigen OO-Design gemacht.

...State Pattern... Das soll natürlich nicht heißen, dass switch völlig überflüssig und immer zu ersetzen ist. Aber nachdenken sollte man schon drüber.

Wikipedia schrieb:

State Pattern - As opposed to using switch

The state pattern can be used to replace switch() statements and if {} statements which can be difficult to maintain and are less type-safe.

[Apollon]

Bei einer fixen Anzahl von Faellen ziehe ich switch vor. Auch wenns 30 Faelle sind. Es sei denn, sie sind wirklich tabellierbar.

[Bashar]

tfa schrieb:

OK, hier kommt der Vorlese-Service:

Weil das, was ich sage, dir nicht gefällt, gehst du davon aus, dass ich das nicht gelesen hätte.

tfa schrieb:

Vielleicht hat er auch unwartbaren Spaghetticode zu einem vernünftigen OO-Design gemacht.

Das hatten wir schon (vielleicht selbst auch mal lesen?) ... Wir wissen nicht, was dieses konkrete switch tut oder warum es existiert. Vielleicht hat es seinen guten Grund, und davon sollte man zuerst mal ausgehen, es sei denn es gibt guten Grund, das anzuzweifeln. Allein die Zahl der Cases ist es nicht.

Schlechte switches erkennt man zum Beispiel daran, dass dieselbe Fallunterscheidung an mehreren Stellen vorgenommen wird. Erst dann hat man ein Wartungsproblem, weil bei Änderungen an einer Stelle die anderen Stellen vergessen werden können.

...State Pattern... Das soll natürlich nicht heißen, dass switch völlig überflüssig und immer zu ersetzen ist. Aber nachdenken sollte man schon drüber.

Nachdenken sollte man immer, gut dass wir uns da einig sind. Deine sonstigen Äußerungen stehen zu dieser Aussage aber im Widerspruch...

Wikipedia schrieb:

State Pattern - As opposed to using switch

The state pattern can be used to replace switch() statements and if {} statements which can be difficult to maintain and are less type-safe.

Hast du dein Wissen über das State-Pattern eigentlich aus Wikipedia? Der Einsatz von Polymorphie statt Type-Switches, wie es in einem prozeduralen Stil üblich wäre, ist eine grundlegende OO-Technik, die natürlich auch bei vielen Patterns zum Einsatz kommt. Das heißt aber erstens nicht, dass diese Ersetzung Gegenstand des State-Patterns ist, und zweitens heißt es nicht, dass es für jedes switch angewendet werden kann oder sollte.