Generics und Enums

[Dejan Vu]

Zitat von Rollo62:

Zeit ist ein nicht zu unterschätzender Faktor für mich,
wenn ihr immer alles perfekt theoretisch analysieren könnt: Hut ab.

...Wenn ich im Vorfeld zu lange versuche das richtige Konzept zu finden werde ich doch meistens
völlig daneben liegen.

Daher sind Pattern, und insbesondere das Erkennen, welches Pattern welches Problem löst, so angenehm. Da muss man nicht mehr großartig analysieren: Man verwendet es einfach und ist damit auf der sicheren Seite. Der Code ist ja lesbar, erweiterbar und skalierbar.

Der Hausbauer kann natürlich jede Wand individuell hochziehen, je nach Statikanforderungen unterschiedlich dick, eine aus Stein, die andere aus Ziegeln, oder zur Abwechslung aus Holz und Lehm (die Südseite muss atmungsaktiv sein) usw.

Oder er verwendet Standardmaterialen in Standardabmessungen.

Bei der ersten Variante muss er seinen Kollegen genau erklären, was wie wo wann und warum genauso gebaut werden muss. In der zweiten Variante wissen die Kollegen das schon.

[bernau]

Ich sehe es natürlich so wie Sir Rufo. Jede Lösung hat seine Vor- und Nachteile. Er hat das ja auch "wie immer" mit verständlichen Beispielen belegt.

Was ich nicht mag ist die Pauschalisierung. Nehme man folgende Aussage.

Zitat von Dejan Vu:

Generics und Enums passen nicht so recht zusammen. Das ist einer der Gründe, warum man auf Enums (weitestgehend) verzichten könnte und sollte. Ein anderer ist, das man sie einfach kaum braucht.

Der erste Satz mag ja noch stimmen. Der nachfolgende Satz ist absolut unbegründet und Wertlos. Mir fehlt da einfach die Begründung.

Genau so bei folgenden Aussagen.

Zitat von Dejan Vu:

Da man nun aber wiederum 'case' Statements nicht verwenden sollte, stimmt es doch wieder

Die Verwendung von Enums ist fast immer ein Indiz für 'schlechte' Programmierung .......

@Dejan Vu: Viele deiner Beiträge sind zwar philosophisch sehr Wertvoll. Bringen aber in der Praxis nichts, weil diese so abstrakt sind und so viele pauschale negative Aussagen haben die in der Regel nicht konkret begründet sind. Bei deinen Beispielen fehlt mir leider der Aha-Effekt. Damit will ich dich nicht persönlich angreifen, sondern mehr konkrete Beispiele für deine Behauptungen bekommen. Vielleicht verstehe ich (und andere) dann eine Beiträge besser .

Übrigens halte ich es so wie Rollo62. Mann muss nicht immer alle möglichen Eventualitäten berücksichtigen. Manchmal ist die spontane schnelle Lösung die bessere Wahl. Oft gibt es während der Programmierphase wieder ganz andere Anforderungen (die man ja selber nicht beeinflussen kann). Dann kann man den Code sowiso nicht einfach erweitern, sondern muss ihn einfach wegschmeißen um dann den optimalen Code zu erzeugen. In vielen Fällen ist man ja auch nur erst einmal der fachfremde Programmierer. Wenn ein neues Projekt angegangen wird, dann verwendet man das Fachwissen, welches man sich beim Programmieren aneignet. Die Sichtweise und das Wissen ändert sich und damit auch der Programmieransatz. Auch deshalb ist der schnelle unkomplizierte Ansatz (manchmal) der Bessere.

Ähm. Ich schweife vom Thema ab. "Generics und Enums" ist für mich hiermit geklärt und der Thread für mich persönlich abgeschlossen.

[Rollo62]

Ich bin natürlich auch ein Fan der reinen Lehre.

Es ist nur leider in der Realität so das ich meine Zeit für banalde Probleme verschwende, wie
z.B. Control zeichnet sich nicht da wo es soll, Click unter letztem ListView sended OnClick,
Bluetooth Verbindung hat Probleme beim Wiederverbinden, usw. usw.

Dafür habe ich noch kein passendes Pattern gefunden.

Für die eigentlich Programmlogik komme ich meist mit dem Grundbaukasten sehr gut klar und wenn
es schön strukturiert ist und ich Zeit übrig habe kann ich auch Patterns, Interfaces, etc. dazupacken.
Das ist aber mehr die Kür für mögliche zukünftige Erweiterungen, und bring kaum konkreten Mehrgewinn.

Im Gegenteil, es ist oft so das ein perfekt designtes Pattern dann nie wieder gebraucht wird.
Ich habe mir daher abgewöhnt als "Hellseher" all zukünftigen Fälle richtig bewerten zu wollen.
Wenn es soweit ist, ist dann immer noch früh genug.

Ich habe eigentlich ein anders "Pattern" entwickelt:
KISS-Prototyp-Pattern:
- erstmal die Machbarkeit zeigen in einem kleiner, mit Grundbausteinen gebauter Lösung.
- dabei etwas mehr über das eigentlich Problem lernen, wenn möglich
- erst beim 2. Anfassen und Erweitern der Lösung würde ich über den Umbau in besser strukturierte Patterns
vorsehen.

Alle vertreter der einen Lehre haben natürlich recht: mit dem von vornherein richtigen Pattern wird das
spätere Ändern und pflegen ein Kinderspiel.
Nur das ich oft feststelle das mein ursprüngliches Pattern gar nicht so optimal war, oder das die
ultra-flexible Erweiterungen in alle Himmelsrichtungen gar nicht mehr gebraucht werden, etc.

Deshalb würde ich mein Vorgehen auch einfach als ein neues "Pattern" beschreiben, und bin damit auch ein
Mitglied im Club der reinen Lehre

Rollo