Einfache Datentypen schnell zusammenbauen?

[Namenloser]

Kommt halt drauf an, ob man das ganze (Java-„Enterprise“-)Gedöhns wirklich braucht, vor allem der Sinn des Interfaces erscheint mir hier fraglich.

Du kannst dir unter Delphi aber, um Tipparbeit zu sparen, Templates (nicht zu verwechseln mit Generics) definieren (das funktioniert dann genau wie die Autovervollständigung von Schleifen etc). Unter Delphi 2006 ging das bei Bearbeiten → Templates, weiß nicht, ob sich das inzwischen geändert hat.

Ich hatte mir damals (bevor es Generics gab) z.B. mal ein solches Template für eine typensichere TObjectList geschrieben:

XML-Code:

<?xml version="1.0" encoding="utf-8" ?>
<codetemplate   xmlns="http://schemas.borland.com/Delphi/2005/codetemplates"
            version="1.0.0">
   <template name="objlist" invoke="manual">
      <point name="TMyObjectList">
         <text>
            TMyObjectList
         </text>
         <hint>
            Klassenname der Liste
         </hint>
      </point>
      <point name="TMyObject">
         <text>
            TMyObject
         </text>
         <hint>
            Klassenname der Listeneinträge
         </hint>
      </point>  
      <description>
         Typensichere Objektliste
      </description>
      <code language="Delphi" context="typedecl" delimiter="|">
<![CDATA[
|*||TMyObjectList| = class(TObjectList)
|*|protected
|*||*|function GetItem(Index: Integer): |TMyObject|;
|*||*|procedure SetItem(Index: Integer; AObject: |TMyObject|);
|*|public
|*||*|function Add(AObject: |TMyObject|): Integer;
|*||*|function Extract(Item: |TMyObject|): |TMyObject|;
|*||*|function Remove(AObject: |TMyObject|): Integer;
|*||*|function IndexOf(AObject: |TMyObject|): Integer;
|*||*|procedure Insert(Index: Integer; AObject: |TMyObject|);
|*||*|function First: |TMyObject|;
|*||*|function Last: |TMyObject|;
|*||*|property Items[Index: Integer]: |TMyObject| read GetItem write SetItem; default;
|*|end;

{ |TMyObjectList| }

function |TMyObjectList|.Add(AObject: |TMyObject|): Integer;
begin
|*|Result := inherited Add(AObject);
end;

function |TMyObjectList|.Extract(Item: |TMyObject|): |TMyObject|;
begin
|*|Result := |TMyObject|(inherited Extract(Item));
end;

function |TMyObjectList|.First: |TMyObject|;
begin
|*|Result := |TMyObject|(inherited First);
end;

function |TMyObjectList|.GetItem(Index: Integer): |TMyObject|;
begin
|*|Result := |TMyObject|(inherited GetItem(Index));
end;

function |TMyObjectList|.IndexOf(AObject: |TMyObject|): Integer;
begin
|*|Result := inherited IndexOf(AObject);
end;

procedure |TMyObjectList|.Insert(Index: Integer; AObject: |TMyObject|);
begin
|*|inherited Insert(Index, AObject);
end;

function |TMyObjectList|.Last: |TMyObject|;
begin
|*|Result := |TMyObject|(inherited Last);
end;

function |TMyObjectList|.Remove(AObject: |TMyObject|): Integer;
begin
|*|Result := inherited Remove(AObject);
end;

procedure |TMyObjectList|.SetItem(Index: Integer; AObject: |TMyObject|);
begin
|*|inherited SetItem(Index, AObject);
end;
]]>
      </code>
   </template>
</codetemplate>

Aufrufen kann man ein solches Template dann, indem man im Editor Strg+Leerzeichen drückt und den Templatenamen (oder zumindest den Anfangsbuchstaben eingibt).

Von solches Fällen abgesehen verfolge ich aber eher die Philosophie, möglichst jedes einzelne Zeichen von Hand einzutippen, gerade weil man sich so drei mal überlegt, ob der Code wirklich so lang sein muss, oder ob es nicht auch einfacher und kürzer geht.

[Dejan Vu]

Wozu benötigst Du für ein DTO ein Interface? Ein reines Datenobjekt ist doch genauso dumm wie ein Interface, also: Weg damit.

Es bleibt also, ein 'Property ' vor jedes Feld zu schreiben und dann mit der Codevervollständigung den Rest erledigen zu lassen. Da es hier eh keine Logik gibt, reicht es doch, die Daten in privaten Feldern abzulegen. Einen Setter, der eventuell den Status des Objektes überarbeitet (Modified, Unmodified) kann man noch nachpflegen.

Ansonsten gibt es -zumindest bei VS- Refactoring-Tools, um z.B. aus einer Klasse das Interface zu extrahieren und -wie schon erwähnt- Templates, um das immer gleiche Tippen von Pattern zu vereinfachen, z.B.:

Delphi-Quellcode:

Procedure SetFoobar (Const Value : String);
Begin
  if Foobar = Value then exit;
  fFoobar := Value;
  RaisePropertyChanged ('Foobar');
End;

Aber wenn dein Beispiel nur ein Beispiel war, dann.. dann sind Refactoring-Tools dein Freund. Da gibt es für Delphi einige Wenige, die sich lohnen, soweit ich das mitbekommen habe.

[himitsu]

Joar, ich hatte mir war auch schonmal gewünscht, daß man sich von delphi automatisch Interfaces erstellen lassen kann.
Die sollte der Compiler z.B. aus Public-Sachen der entsprechend markierten Objekt-Definition generieren.

Ansonsten könnte man sich natürlich auch verschiedene Helferlein erstellen, welche (ähnlich der Klassenvervollständigung) die Definitionen synchronisieren.

[Dejan Vu]

Na, ganz so synchronisierend geht das dann in VS doch nicht. Mit Resharper deklarier ich im Interface eine neue Property und wähle dann 'Implement member in derived classes'.

Aber 'extract interface' gibt es doch in Delphi....

[himitsu]

Wer die Features der IDE nicht nutzt, ist selber Schuld.


Du fängst dort an:

Delphi-Quellcode:

type
  |

danach tippst du Folgendes

Code:

classc[strg+leer]Adresse[enter]

und dann wieder hoch zur Deklaration (Strg+Shift+Hoch) und ab in den privaten Teil

Code:

propgs[strg+leer]vorname[tab]string[enter]

hoch

Code:

propgs[strg+leer]nachname[tab]string[enter]

hoch

Code:

propgs[strg+leer]straße[tab]string[enter]

hoch

Code:

propgs[strg+leer]hausNr[tab]Integer[enter]

fertig
(für String und Integer kann man natürlich auch wieder die Codevervollständigung verwenden, wenn man die nicht ausschreiben möchte)


Ich hab mir dafür allerdings das fehlende Property-Template "progs" für propety {Name}: {Type} read F{Name} write Set{Name} selber gebastelt.





Oder

Delphi-Quellcode:

type
  TAdresse = class
  private
  public
    constructor Create; override;
    destructor  Destroy; override;
                                  
    property Vorname:  string read FVorname  write SetVorname;
    property Nachname: string read FNachname write SetNachname;
    property Straße:   string read FStraße   write SetStraße;
    property HausNr:   string read FHausNr   write SetHausNr;
  end;

Und dann nur noch die Klassenvervollständigung (Strg+Shift+C).

[DeddyH]

Der Konstruktor von TObject ist weder virtuell noch dynamisch, kann also nicht überschrieben werden (d.h. "override" wech)

[himitsu]

Zitat von DeddyH:

Der Konstruktor von TObject ist weder virtuell noch dynamisch, kann also nicht überschrieben werden (d.h. "override" wech)

Joar, sag das mal Delphi.

Ist wohl nach dem Motto "besser zu viel, als zu wenig", denn die Override hatte Delphi generiert.

[Mavarik]

Zitat von Namenloser:

... vor allem der Sinn des Interfaces erscheint mir hier fraglich.

Ich kann das gut verstehen...

Seit ARC, bin ich ein Fan von Interfaced Objects... Denn seit ich für Android & iOS Programmiere, vergesse ich auf Windows Seite notorisch das Free...

Auch für die Wiederverwendbarkeit des Codes... Stichwort "Dependency Injection" ist es sinnvoll.

Grüsse Mavarik

[jaenicke]

Zitat von Namenloser:

Ich hatte mir damals (bevor es Generics gab) z.B. mal ein solches Template für eine typensichere TObjectList geschrieben:

Dann doch lieber als .inc Datei ohne die Klassen alle hinzuschreiben... das ging auch schon bevor es Generics gab. Das sah bei mir so aus:

Delphi-Quellcode:

{$IFNDEF COMPILER_14_UP}
  TTypedObjectListItem = TPosScreenElement;
{$define NoNewTypeSection}
{$include 'TypedObjectListTemplate.inc'}
  TPosScreenElementList = class(TTypedObjectListTemplate)
{$ELSE}
  TPosScreenElementList = class(TObjectList<TPosScreenElement>)
{$ENDIF}

Und so weiter... lief mit Delphi 5 wie mit XE.

Da die Deklarationen ansonsten bei der generischen Variante gleich waren, lief der Quelltext mit Template und echten Generics parallel.

[Dejan Vu]

So richtig lesbar/übersichtlich ist das ja nicht gerade...