Wozu sind Attribute gut ?

[Der schöne Günther]

Ich sitze mit großen Augen still in der Ecke und lausche. Vielen Dank für weiteres Material, interessantes Thema!

[Patito]

Zitat von Der schöne Günther:

Ich sitze mit großen Augen still in der Ecke und lausche. Vielen Dank für weiteres Material, interessantes Thema!

Nunja, sonderlich viel Material wird es da nicht mehr geben
1) Für die von Dir genannten Anwendungsfälle ORM/Serialisierung ist es eben etwas ungeschickt die
Methode jedes mal zur Laufzeit zusammenzustückeln. Wenn man das ganze gleich richtig macht ist man
eben gleich eine Größenordnung schneller. Attribute sparen da eben nur etwas Tipparbeit (für Code,
den man gerade beim solchen Anwendungsfällen eh vollautomatisch erzeugen kann).

2) Die Syntax ist eben Java/C# und passt nicht ganz zu Pascal.

3) Man hat für den Code nicht mehr sonderlich viele Compiler zur Auswahl.

[Lemmy]

Zitat von Patito:

1) Für die von Dir genannten Anwendungsfälle ORM/Serialisierung ist es eben etwas ungeschickt die
Methode jedes mal zur Laufzeit zusammenzustückeln. Wenn man das ganze gleich richtig macht ist man
eben gleich eine Größenordnung schneller. Attribute sparen da eben nur etwas Tipparbeit (für Code,
den man gerade beim solchen Anwendungsfällen eh vollautomatisch erzeugen kann).

ich persönlich finde, dass die Attribute im Bereich ORM verdammt viel Tipparbeit sparen. z.b. im Bereich der Wertüberprüfung. Da reicht mir dann eine generische Methode die alle Attribute prüft. Und den Wertbereich kann ich direkt beim Property erfassen, dokumentieren und nicht erst im Setter. Wo ich evtl. die Prüfung gar nicht haben will (z.B. beim Laden eines Projektes) und diese wieder kompliziert ausschalten muss.

weiterhin geht es weniger um "Methoden zur Laufzeit zusammenstückeln" sondern eher generische/parametrisierte Methoden zu haben, die mit den Attributen arbeiten, ohne dass ich gleich jedes Property einer Klasse selbst zu einer Klasse erheben muss (was durchaus interessant sein kann, aber manchmal halt nicht machbar ist).

und wegen

Zitat von Patito:

3) Man hat für den Code nicht mehr sonderlich viele Compiler zur Auswahl.

selten so gelacht. wie viele Compiler kennst Du denn, die VCL-Code compilieren können? Das ist ja wohl DAS Vendor lock-in schlecht hin....



Grüße

[OlafSt]

Ob man wohl ein simples Beispiel zeigen könnte, die mir Deppen den Nutzen klar aufzeigen ? Die Sache mit dem ENUM weiter oben z.B. ist spannend - es fehlt aber der Fitzel Programmcode, der mir sagt: Jo, det isses. Was ORM ist, ist mir auch ein Rätsel, mag aber daran liegen, das ich nicht studiert hab sondern nur 30 Jahre Praxiserfahrung in den Knochen...

[mkinzler]

ORM = Object Relational Mapping

http://de.wikipedia.org/wiki/Objektr...nale_Abbildung

[Sherlock]

Zitat von OlafSt:

Ob man wohl ein simples Beispiel zeigen könnte, die mir Deppen den Nutzen klar aufzeigen ? Die Sache mit dem ENUM weiter oben z.B. ist spannend - es fehlt aber der Fitzel Programmcode, der mir sagt: Jo, det isses. Was ORM ist, ist mir auch ein Rätsel, mag aber daran liegen, das ich nicht studiert hab sondern nur 30 Jahre Praxiserfahrung in den Knochen...

Ich schließe mich da mal an. Der Enum Ausschnitt sieht ja erstmal recht "übersichtlich" aus. Eine (beispielhafte) Verwendung des ganzen wäre das Sahnehäubchen.

Sherlock

[Union]

Hier ist ein schönes Beispiel.

[Furtbichler]

Übrigens kann man die Geschichte mit den Attributen auch ganz schön übertreiben. Wenn ich mehr Attribute als Methoden habe, wird es für mich fragwürdig, diese in dieser Fülle einzusetzen.

Im Vordergrund sollte übrigens nicht die Ersparnis von Tipparbeit stehen, sondern die Lesbarkeit des Codes. Hier können Attribute -eben weil sie kurz und knackig sind- wirklich dazu beitragen, das der Code lesbarer wird (Stichwort 'ORM').

Ich persönlich finde das gezeigte Beispiel mit den Enums auf den ersten Blick übrigens schlecht lesbar.

Das Beispiel von Union (bzw. sein Link) ist schon schön, verstößt aber (ein wenig) gegen das Prinzip 'Information Hiding', wobei man anmerken muss, das es keinen anderen sinnvollen Platz für Attribute als im Interface-Abschnitt einer Klassendefinition gibt.

Ich persöhnlich gehe mit diesen Dingen eher konservativ um, denn da werkelt für mich zu viel unsichtbarer Code im Hintergrund. Wenn die Aussage hinter einem Attribut nicht klar ist, ist es deplaziert.

[jfheins]

Ich kann hier mal ein Beispiel von mir zeigen:

Code:

    public enum COMM_Command : byte
    {
        #region Paste Bereich

        [CommandInfo(Category.General, "Ping ausführen", PrimaryName = "")]
        PING = 0,
        [CommandInfo(Category.Response, "ACK", PrimaryName = "")]
        NACK = 2,
        [CommandInfo(Category.GetVariable, "Status", Conversion = CommType.Status)]
        REQ_STATE = 6,
        [CommandInfo(Category.GetVariable, "Zyklen")]
        REQ_CYCLES = 7,
        [CommandInfo(Category.GetVariable, "Motor (Promille)", Unit = "‰")]
        REQ_MOTOR_PROMILLE = 8,
        [CommandInfo(Category.GetVariable, "Bremse (Promille)", Unit = "‰")]
        REQ_BRAKE_STATE = 10,
        [CommandInfo(Category.GetSensor, "Encoder (Gegenrad)", Unit = "U/min")]
        REQ_ENCODER_MOTORWELLE = 12,
        [CommandInfo(Category.GetSensor, "Gefahrene Strecke", Unit = "m", Conversion = CommType.thousands)]
        REQ_DRIVEN_DISTANCE = 14,
        [CommandInfo(Category.GetSensor, "Bandsensor (binär)", Unit = "bool")]
        REQ_ROPE_SENSOR_STATE = 16,
        [CommandInfo(Category.GetSensor, "Temperatur", SecondaryName = "Sensor", Unit = "°C")]
        RES_TEMPERATURE = 81,
// ...
        [CommandInfo(Category.SetVariable, "Status", Conversion = CommType.Status)]
        SET_STATE = 135,
        [CommandInfo(Category.SetVariable, "Motor (Promille)", Unit = "‰")]
        SET_MOTOR_PROMILLE = 136,
        [CommandInfo(Category.SetVariable, "Bremse (Promille)", Unit = "‰")]
        SET_BRAKE_PROMILLE = 137,
// ...
        [CommandInfo(Category.Command, "Start", PrimaryName = "")]
        CMD_START = 200,

Das ist jetzt nur ein kleiner Ausschnitt des enum.

Die Attribute ermöglichen mir hier eine GUI ohne Wasserfallertige Fallunterscheidungen. Es gibt eine Combobox wo man die Kategorie auswählen kann ("Variable setzen", "Befehl senden"), die zweite Combobox enthält dann die möglichen Aktionen. Und wenn ein Wert dazu gehört, erscheint darunter eine Textbox.

Das ganze hätte sich auch mit einer Command-Klasse lösen lassen - diese Art hat aber den Vorteil dass der struct (der ein feld mit dem enum enthält) einfach in ein Bytearray konvertiert werden kann. Das ganze kommuniziert nämlich über einen COM-Port mit einem Mikrocontroller. Außerdem ist es einfacher, den enum in den beiden Codebasen gleich zu halten. (Der ganze Inhalt des enums wird inzwischen mit einer Excel-Tabelle generiert - so als Dokumentation)

Die Sache mit den Attributen hat in meinen Augen noch den zusätzlichen Vorteil, dass die Infos im Code "nah beisammen" sind. Fügt man ein Element ohne Attribut hinzu, fällt das sofort auf. (Die Regelmäßigkeit ist unterbrochen) Würde ich die Daten separat in einem Dictionary<COMM_Command, Attribute> ablegen, dann fällt das nicht so flott auf.