Wozu sind Attribute gut ?

[Furtbichler]

Zitat von jfheins:

Nicht dass ich jetzt meine Arbeit abwälzen will, aber mich würden andere Ansätz schon interessieren.

Darstellung ('Description' Attribut) als Attribut, Parametrierung als Klasse. Zugriff auf die Parameter über eine Dictionary (wie Du schon angedeutet hast).

Vorteil: Skalierbar, d.h. die Parameterklasse kann wachsen, ohne das die Lesbarkeit leidet. Bei der Verwendung von Attributen ist das nicht gegeben, denn irgendwann kleben u.U. über jedem Enum-Wert mehrere Duzend Attribute.

Die Initialisierung des Lookups erfolgt z.B. im statischen Konstruktor. Per Codefolding ist das dann unsichtbar und interessiert eh keine Sau. Die Übersichtlichkeit ist genauso 'toll' wie bei der Verwendung der Attribute.

Letztendlich nimmt sich das nicht viel, aber die Dictionary-Lösung ist erstens ein allgemeingültiges Pattern und zweitens eben (ich wiederhole mich) skalierbar.

Vorteile bei der ausschließlichen Verwendung von Attributen sehe ich nicht.

Ergo (meine Punktezählung)... 2:0 für die altbackene Lösung. Für mich zählt kompakter Code nicht (mehr). Lesbarkeit ist alles.

Frage: Wie lokalisierst (d.h. übersetzt ggfs in andere Sprachen) Du eigentlich die 'Description'-Attribute?

Ach, und zum Code: Wieso verwendest Du keine Viewmodels? (Teeren und Federn sollte man dich )

[jaenicke]

Zitat von Furtbichler:

Vorteile bei der ausschließlichen Verwendung von Attributen sehe ich nicht.

Die gibt es aber. Attribute haben allgemein den Vorteil, dass sie direkt an den entsprechenden Codeteilen stehen. Wenn man nun dort etwas ändert, sieht man auch sofort, dass das auch geändert werden muss. Insbesondere fällt es sofort auf, wenn das Attribut bei einem neuen Element fehlt bzw. man kann es beim Initialisieren der Daten auch über die RTTI direkt prüfen.

Solange man nur alleine an einem Projekt arbeitet, fällt das nicht so sehr ins Gewicht, da man sich selbst eher dran erinnert, "dass da ja noch was war", aber wenn auch andere daran arbeiten, wissen diejenigen das schlicht nicht immer.

An solchen Stellen dann immer entsprechende Kommentare anzubringen ist zwar möglich, aber auch keine schöne Lösung. Da finde ich es wie auch bei Funktions- und Variablennamen besser, wenn man nur wenige Kommentare braucht, weil man schon aus einem Codeausschnitt alles schnell herauslesen kann.

[Medium]

Ich dagegen bin dazu übergegangen fast alles was ich an Combobox-Einträgen so brauche über meine Datenbanken "zusammenzuqueryn", dank glaube ich ganz netter Strukturen geht das sogar mit einer Standardfunktion. Erleichtert allen voran auch das Übersetzen ohne Neucompilieren. Macht aber auch nur wirklich Sinn, wenn die DB entweder eh grbraucht würde, oder embedded ist. Ich versuche so viel Daten und deren Abhängigkeiten voneinander in die DB zu gießen, und im Programm dann nur noch mittels Kreuztabellen die Dinge zu verknüpfen. Dabei ist auch praktisch, dass ich Änderungen in gewissem Umfang machen kann, und der Kunde muss nichtmals sein Programm neu starten um diese nutzen zu können.

[Uwe Raabe]

Zitat von Medium:

Ich dagegen bin dazu übergegangen fast alles was ich an Combobox-Einträgen so brauche über meine Datenbanken "zusammenzuqueryn", dank glaube ich ganz netter Strukturen geht das sogar mit einer Standardfunktion. Erleichtert allen voran auch das Übersetzen ohne Neucompilieren. Macht aber auch nur wirklich Sinn, wenn die DB entweder eh grbraucht würde, oder embedded ist. Ich versuche so viel Daten und deren Abhängigkeiten voneinander in die DB zu gießen, und im Programm dann nur noch mittels Kreuztabellen die Dinge zu verknüpfen. Dabei ist auch praktisch, dass ich Änderungen in gewissem Umfang machen kann, und der Kunde muss nichtmals sein Programm neu starten um diese nutzen zu können.

Ich weiß nicht, ob ich das so machen würde. Stimmt nicht - ich weiß, daß ich es garantiert nichts so machen würde. Genauso hat das mal vor Jahren ein frisch gebackener Diplom-Informatiker realisiert - auch mit dem Hinweis der leichten Anpassbarkeit der Texte an andere Sprachen. Problematisch wurde es allerdings, als die Anzahl der Optionen in einer neuen Programmversion erhöht wurde und dies in jeder Kundendatenbank von Hand nachgetragen werden musste. Das automatische Ergänzen war auch keine wirkliche Erleichterung und hat den Code unnötig verkompliziert. Richtig böse wird es aber dann, wenn sich die Bedeutung bestehender Einträge ändert und die vorhandenen Texte in den Kundendaten angepasst werden müssen.

Übersetzungen gehören m.E. nicht in die Datenbank - zumindest nicht in die mit den Arbeitsdaten.

[Medium]

Da kommt es vermutlich auch wieder ein wenig auf die Art der Daten an. Bei uns sind das oftmals Dinge wie Rezeptbetrieb in einer intustriellen Produktionsanlage. Wenn dort z.B. ein Rezept ausgewählt wird, soll per Combobox ein Zielmischer wählbar sein. Ich habe alle Quellbehälter und Zielmischer in meiner DB, sowie deren Inhalte. Zudem eine Kreuztabelle, die mir sagt welche Quellen auf welche Ziele fahren können. Dann steht im Rezept, welche Rohstoffe nötig sind. Aus diesen Infos kann ich dann eine Liste der Zielmischer erzeugen, die von allen Quellen, die die nötigen Stoffe beinhalten erreicht werden können. Alle Behälterdaten inkl. ihrer Namen stehen auch in der DB, so dass ich meine Combobox damit gleich befülle. (Und den Index in die Objects-Property.)

Baut der Kunde dann mal einen neuen Behälter dazu, muss ich zur EInbindung in den Vollautomatikbetrieb einfach nur den neuen Tank in die Behältertabelle packen, und in der Kreuztabelle mit seinen Zielen verbinden. Und schon ist die neue Komponente "on the fly" voll einsatzfähig. Unsere Programme sind halt auch kundenspezifisch, und der Kundenstamm besteht eher aus wenigen großen als vielen kleinen. Dadurch fällt das "Breiten-Update-Problem" quasi weg. (Man hätte dieses aber auch bei in-code Daten, da muss dann eben überall das Programm getauscht werden, statt die DB angepasst.)

Bleibt am Ende fast wieder nur: Es kommt halt immer darauf an, wofür man die Dinge genau einsetzt

Edit: Jetzt erst deinen letzten Satz gesehen, wodurch mir klarer wurde, wo du das Problem siehst. Ich habe es in einem Fall so gelöst, dass ich die Übersetzungen in eine separate Tabelle mit Fremdschlüssel und Tabellenname gepackt habe. War im Programm dann eine andere Sprache gewählt, wurden die Texte aus der jeweiligen Übersetzungstabelle geholt. Zugegeben: Das war an ein bestehendes Projekt "angebaut", und ginge vermutlich besser wenn man es von Anfang an voll integriert. Bei Übersetzungen statischer Texte in der GUI, also Dingen, die nichts mit den Arbeitsdaten zu tun haben, nutzen wir ein 3rd Party Tool.

[Furtbichler]

Zitat von jaenicke:

Zitat von Furtbichler:

Vorteile bei der ausschließlichen Verwendung von Attributen sehe ich nicht.

Die gibt es aber. Attribute haben allgemein den Vorteil,..

Absolut, ich meinte auch "ausschließlich", d.h. alles immer nur noch mit Attributen zu machen.

Bezüglich der Übersetzungen/Lokalisierung neige ich zu einer wie auch immer gearteten Standard-Lösung, die bei Delphi eher in Richtung "kommerziell und ausgereift" tendiert. Mir sind DBs am liebsten, da sie auf einfache Weise das Paradigma des zentralen Zugriffs umsetzen. Netzdateien gingen auch, aber wo kein Netz ist, bleibt nur eine DB.

[Insider2004]

Ja die guten alten Attribute. Eingekauft von .net, java und sonstigen Meta-Sprachen. Passen leider überhaupt nicht zu Pascal, weil sie schlichtweg nicht nötig sind. Zinnen und Balkönchen am Delphi-Schloss. Wenn ihr richtige Software Engineers werden wollt, dann ignoriert Attribute einfach.

[jaenicke]

Zitat von Insider2004:

Passen leider überhaupt nicht zu Pascal, weil sie schlichtweg nicht nötig sind. Zinnen und Balkönchen am Delphi-Schloss. Wenn ihr richtige Software Engineers werden wollt, dann ignoriert Attribute einfach.

Stimmt und überhaupt, Codeeinrückung ist doch auch schlichtweg nicht nötig. Zinnen und Balkönchen am Quelltext. Und überhaupt, warum überhaupt mehrere Units, warum nicht gleich alles in einer, ist doch viel besser, alles andere ist doch gar nicht nötig, das wäre doch viel übersichtlicher.

[mkinzler]

Wahre Profis proggen eh in Maschinencode, denn schon (Makro-)Assembler verwässern den Code.

[Furtbichler]

Na, vielleicht meinte der Insider2004 nur, das man erst das Handwerkszeug lernen sollte, bevor man mit dem Ausschmücken anfängt. Hier isses aber nun einmal so, das Attribute nur ein weiteres Werkzeug zur Modellierung der Lösung sind. Klar sollte man damit nicht anfangen, wenn man die ersten 'Hello World'-Programme schreibt, aber wenn Attribute überflüssig sind, dann sind es Klassen auch.

Allerdings...

Zitat von Insider2004:

Eingekauft von .net, java und sonstigen Meta-Sprachen.

Was sind Meta-Sprachen?

Zitat:

Wenn ihr richtige Software Engineers werden wollt, dann ignoriert Attribute einfach.

Das ist die schmerzhafteste Aussage des Jahres.