Also entgegen der Realität ist es in dem Fall am einfachsten, den Motor zu fragen, was er denn tanken will. Wie man das im Detail realisiert (ob man direkt Auto.Motor.Kraftstoff anspricht oder die Abfrage in einer Funktion Auto.GetKraftstoff kapselt) und ob man dabei mit Objekten oder Interfaces arbeitet, ist dabei m.E. nebensächlich.
Puh. Er versteht mich.
Für mich ist die Frage interessanter, wie die Objekte (deren Schnittstellen weiter verwendet werden) ertzeugt und verwaltet werden.
Wer ist Owner der Objekte? Gibt es Verschachtelungen? Wer kümmert sich um die Lebensdauer der Objekte?
Meine Welt besteht fast komplett aus typisierten Objektlisten. Objekte die potentiell Property verschiedener anderer Objekte sein können haben ein property "userlist". Ihr Owner (immer eine typisierte Liste) implementiert eine cleanup Methode welche Items mit userlist.count=0 freigibt. Die cleanup methode wird aufgerufen, wenn ein neues Objekt von der Liste verlangt wird. Dort werden die Objekte auch erzeugt.
Beispiel (stark vereinfacht):
methode fuhrpark.fahrzeug(ckennz:string):tfahrzeug;
CleanupInterneListe(cKennz);
result := HolefahrzeugAusInternerListe(ckennz);
if result = NIL then result := erzeugeFahrzeug(ckennz);
InterneListe.add(result);
end;
und wo ein Fahrzeug benötigt wird:
Einsatzfahrzeuge.add(fuhrpark.fahrzeug('K-BW-5050'))
// implementiert ungefähr so:
methode EinsatzFahreuge.add(kfz:tfahrzeug)
ffahrzeuge.add(kfz);
kfz.adduser(self);
end
destructor Einsatzfahrzeuge.destroy;
RemoveMefromProperties;
ffahrzeuge.free;
inherited;
end
Anything, carried to the extreme, becomes insanity. (Exilant)