Hallo,
Das ist doch in meinem genannten Framework-Beispiel gar nicht meine Baustelle, sondern die des Anwenders.
Das werde ich wohl nie nachvollziehen können, da bei meinen Frameworks ich der Anwender bin und diese immer aus einer konkreten Problemstellung entstehen. Und dann stecke ich bereit mitten in Klassenstrukturen und dann wird das auch damit gelöst.
@beliebigbenannter
Ich denke (wie DeddyH) auch, dass man beide Bereiche nicht durcheinander werfen sollte.
Ja, vieleicht übertreibe ich hier und da etwas, wie diejenigen die Interfaces als alleiniges Allheilmittel ansehen (oder es zumindest so aussehen lassen).
Man muss halt abwägen, wann der Mehraufwand der Interfaces Sinn macht und wann nicht.
Vollkommen ja, bloß bei mir kommt es oft so an das Interface die einzige Lösung sind und der Mehraufwand einfach unter den Teppich gekehrt wird.
Mir gefällt die Umsetzung der Interfaces in Delphi auch nicht so ganz.
Es wäre schön, wenn man nur
Delphi-Quellcode:
IMyIntf = Interface
property MyProp: Integer read write;
end;
angeben müsste (wobei "read write" auch Standard sein, also weggelassen werden könnte)
Du hast recht, read write müsste der Standard sein. Dann vieleicht auch so:
Delphi-Quellcode:
iMyInterface
property ReadWritProp: Integer;
property ReadonlyProp: Integer readonly;
Ich würde nicht zwanghaft Interfaces einsetzen, aber bei etwas komplexeren Projekten im Regelfall schon.
Erst mal schauen wie breit und tief das Problem ist. Ist es er flach und breit dann Klassenstruktur. Ist es tief und schmal dann Intefaces. Beim Übergang von einem zum andern, der fließend ist, aber darauf achten das Intefaces auch Nachteile haben. Ein Nachteil kann auch sein, dass wenn man nicht selbst der Anwender ist, es dieser auch falsch benutzen kann, was einem später wieder schlimm auf den Kopf fallen kann.
einbeliebigername.