Designfrage: Pest oder Cholera

[stahli]

Dem Vorschlag von Stevie würde ich mich anschließen.

Daniel hatte in seinem D2010-Video die Propertyattribute und die neue RTTI vorgestellt.
Darauf aufbauend habe ich eine Objektserialisierung realisiert.
Einer Methode wird ein Objekt übergeben, das beim schreiben die "markierten Propertys" exportiert (MyProp=MyValue), bzw. beim einlesen prüft, ob eine markierte Property "MyProp" im Objekt existiert und weist dem MyValue zu.

Es muss also nicht für jedes Objekt eine spezifische Export/Import-Funktion geschrieben werden.

[BerndS]

Hallo,
ich würde das über "Unit-Aliasse" lösen und so die Klasse TQuery gegen eine Dummyklasse austauscht. Mache das bei Quickreport so, um TQuery durch TFIBDataset zu ersetzen.

Gruß Bernd

[himitsu]

Unit-Aliasse sind eher für "Notfälle" gedachtgeeignet.

Und was macht macht man, wenn mn an der einen Stelle in die XML speichern will und an anderer Stelle in die DB,
oder wenn es per Programm-Optionen umschaltbar sein soll?

[Stevie]

Schon amüsant (oder sollte ich sagen schockierend?), auf was für Ideen hier manche kommen (vor allem fast ausschließlich >=Delphi 2010 User) :shock:

[Iwo Asnet]

Der Vorschlag von Stevie ist was für Hacker. ;-) So würde ein guter IExporter umgesetzt werden.

Die Frage lautete doch aber, was vom Klassendesign besser ist.

Jeder Klasse ein 'ExportTo' zu spendieren, ist imho nicht ganz richtig (im Sinne der Ästhetik), denn einem Haus ist es egal, ob es sich irgendwo hin exportieren kann. Es steht einfach nur da und soll auch bei einem Sturm nicht umpurzeln (z.B.)

Wenn man das Haus exportieren will, beauftragt man einen Spezialisten, der das kann, nämlich einen, der die IExporter-Schnittstelle implementiert. WIE der das macht, und WAS er genau exportiert (Blaupause, Konzept, Hausbaukasten, Architekt etc.) ist wurscht.

Der Nachteil der Vorgehensweise, eine neues Verhalten in den Klassen zu hinterlegen ist der, das man Beziehungen schafft (TExportableClass), die rein logisch gar nicht vorhanden sind.

Was hat denn z.B. ein Haus mit einem Kuchen zu tun? Bloß weil beide exportierbar sind? Sie stehen aber in einer Beziehung, weil beide von TExportableClass abgeleitet sind.

Klar, man kann auch mit Interfaces arbeiten und implementiert dann kreuz und quer und je nach Lust und Laune mal hier ein IExportable, mal dort. Kraut & Rüben sind bei so einem Konzept im wahrsten Sinne des Wortes vorprogrammiert.

Ich lasse meine Klassen so kompakt und klein, wie es geht. Mit der Maxime hatte ich noch nie Probleme. Es ist manchmal nur etwas schwieriger, es 'richtig' zu machen. Dafür sieht so ein Klassenkonzept immer ordentlich aus und ist es auch.

[Stevie]

Zitat:

Zitat von Iwo Asnet (Beitrag 1107937)

Der Vorschlag von Stevie ist was für Hacker. Die Frage lautete doch aber, was vom Klassendesign besser ist.

Hacker? ROFL! Ich empfehle dir mal, das hier zu lesen, um nen Plan zu bekommen, was ich meinte.

P.S. Grundlagen der Serialisierung in .NET Framework

[implementation]

Zitat:

Zitat von Stevie (Beitrag 1107938)

das hier zu lesen

Katze Garfield :mrgreen::roteyes::spin:

[Iwo Asnet]

Zitat:

Zitat von Stevie (Beitrag 1107938)

Zitat:

Zitat von Iwo Asnet (Beitrag 1107937)

Der Vorschlag von Stevie ist was für Hacker. Die Frage lautete doch aber, was vom Klassendesign besser ist.

Hacker? ROFL! Ich empfehle dir mal,... zu lesen

Kenn ich doch.
ROFL? RTTT! (=Read The Thread Title): Hier gehts um Klassendesign (=Architekten), nicht um Implementierung (=Handwerker, Hacker).

[Stevie]

Mal vorweg: unabhängig von den aktuellen Meldungen um LulzSec und co empfinde ich persönlich Hacker als Beleidigung (mag damit zusammenhängen, dass mein Info Lehrer damals im Grundkurs Informatik uns immer so genannt hat, wenn wir ohne was aufs Papier zu schreiben die - natürlich simple - Lösung gleich runtercodiert haben) ;)

Ich habe übrigens nicht nur den Thread Titel gelesen, sondern auch den ganzen Post.
Dementsprechend ist die Nutzung der RTTI und/oder des ISerializable (oder wie du es auch sonst nennen willst) Interfaces für Standard und benutzerdefinierte Serialisierung durchaus eine Designentscheidung und hat erstmal nix mit der Implementierung zu tun.

Um dein Beispiel von dem Haus und dem Kuchen nochmal aufzugreifen, käme das Konzept über RTTI/Attribute der Bereitstellung eines Bauplans/Rezepts gleich, die diese Klasse gleich mitliefert aber dennnoch nichts direkt mit der Implementierung zu tun hat (in dem Programm, wo man keine Serialisierung braucht, kann man die RTTI auch ausschalten, wenn man mag).

Kritisch sehe ich ähnlich wie du im Sinne der Trennung die Implementierung des Interfaces, denn dann hast du wieder eine Abhängigkeit und sei es auch nur auf ein ISerializer, IExporter oder wie auch immer.

[Namenloser]

Zitat:

Zitat von Stevie (Beitrag 1107951)

Mal vorweg: unabhängig von den aktuellen Meldungen um LulzSec und co empfinde ich persönlich Hacker als Beleidigung

Wieso? Ein Hack ist eine unkonventionelle Lösung. Konventionell ist in diesem Fall das Anwenden von Design-Patterns etc., was u.U. einigen Overhead im Code zur Folge hat. Du hingegen benutzt einfach die die RTTI und sparst dir damit das ganze Gedöhns. Das könnte man schon irgendwie als „Hack“ bezeichnen. Aber das ist doch nix schlimmes...