Code Optimierung gesucht

[alda]

Unabhängig von den Listen solltest Du auf jeden Fall auch deine Klasen-Struktur überdenken - aber ich vermute, dass Dein Code schon Älter ist und eine Anpassung sehr aufwendig ist. Hier ein paar Ideen:

• auf keinen Fall mehrere Listen - damit ist jede verwendete Codestelle anzupassen, sofern ein neuer Hersteller hinzukommt. (da schließ ich mich dem Rest an)
• Warum von TComponent ableiten? Egal für welchen aktuellen Zweck erachte ich das als nicht sinnvoll.
• Ableitungen pro Autohersteller halte ich im allgemeinen auch nicht für sinnvoll
• die Ableitungen pro Hersteller scheinen aufgrund der als bool (vereinfachten) Eigenschaften vorgenommen worden zu sein, sollten wiederum aber auch eigene Klassen sein (ich nenne Sie mal TAusstattung), da die Vererbung die Flexibilität hier stark eingrenzt.
• Einsatz von Interfaces für bestmögliche Entkopplung und Testbarkeit

[Dejan Vu]

Zitat von alda:

...

• Ableitungen pro Autohersteller halte ich im allgemeinen auch nicht für sinnvoll

...

Sind sie aber. Alles andere (Enum/ Eigenschaft 'Fahrzeugtyp') bedeutet auch: Verletzung des OCP, d.h. die 'Auto-Klasse' müsste jedes mal angefasst werden, wenn eine neue Type mit spezifischen Eigenschaften hinzukommt. Hast Du dagegen pro Hersteller eine eigene Klasse, bleiben alle existierenden Klassen beim Hinzufügen einer neuen Klasse unangetastet, was den Code wesentlich robuster, d.h. stabiler macht.

Nur wenn es je Hersteller garantiert keine individuellen Eigenschaften gäbe (was hier nicht er Fall ist), muss man keine einzelne Klassen bilden.

EDIT: Habe deinen Post gerade noch einmal gelesen: Du meinst, ein TAuto, aber je Hersteller unterschiedliche Ausstattungen? Das wäre eine Möglichkeit, wobei diese Architektur impliziert, das man den Hersteller wechseln kann. Weiterhin müsste man die Eigenschaft 'Ausstattung' jedes Mal casten, um auf spezifische Eigenschaften eines Herstellers zu gelangen.
Ferner müsste die Zuordnung 'Fahrzeugtyp => Ausstattungsklasse' in einer Factory erfolgen, die der Konstruktor der Klasse TAuto aufruft, damit OCP nicht verletzt wird:

Delphi-Quellcode:

Type
  TAuto = Class
    FHersteller : THersteller;
    FAusstattung : TAusstattung;
  public
    constructor Create (aHersteller : THersteller);
    Property Ausstattung : TAusstattung read FAusstattung;
  end;

...
constructor TAuto.Create(aHersteller : THersteller);
begin
  FAusstattung := TAusstattungFactory.Create(aHersteller);
end;

[alda]

Zitat von Dejan Vu:

Zitat von alda:

...

• Ableitungen pro Autohersteller halte ich im allgemeinen auch nicht für sinnvoll

...

Sind sie aber. Alles andere (Enum/ Eigenschaft 'Fahrzeugtyp') bedeutet auch: Verletzung des OCP, d.h. die 'Auto-Klasse' müsste jedes mal angefasst werden, wenn eine neue Type mit spezifischen Eigenschaften hinzukommt. Hast Du dagegen pro Hersteller eine eigene Klasse, bleiben alle existierenden Klassen beim Hinzufügen einer neuen Klasse unangetastet, was den Code wesentlich robuster, d.h. stabiler macht.

Nur wenn es je Hersteller garantiert keine individuellen Eigenschaften gäbe (was hier nicht er Fall ist), muss man keine einzelne Klassen bilden.
[/DELPHI]

Da stimme ich Dir zu, allerdings sehe ich den Hersteller eher als Baustein, weniger als Herzstueck der Auto-Klasse an. Die Frage wäre welche Informationen des Herstellers benötigt werden und was damit im weiteren Verlauf ermittelt werden soll.

Zitat von Dejan Vu:

EDIT: Habe deinen Post gerade noch einmal gelesen: Du meinst, ein TAuto, aber je Hersteller unterschiedliche Ausstattungen? Das wäre eine Möglichkeit, wobei diese Architektur impliziert, das man den Hersteller wechseln kann. Weiterhin müsste man die Eigenschaft 'Ausstattung' jedes Mal casten, um auf spezifische Eigenschaften eines Herstellers zu gelangen.
Ferner müsste die Zuordnung 'Fahrzeugtyp => Ausstattungsklasse' in einer Factory erfolgen, die der Konstruktor der Klasse TAuto aufruft, damit OCP nicht verletzt wird:

Ja, oder so ähnlich. Die Frage ist, ob er in seinem Programm die Ausstattungen je Auto konfigurieren kann und welche Rolle der Hersteller spielt. Letztendlich gibt es ja auch oft den Fall, dass Hersteller A ein Auto (teilweise) anfertigt und dann Hersteller B dieses fertigstellt (z.B. individuelle Innen-Austattung) und sein Logo draufsetzt (z.B. Mercedes CITAN).
Ich sehe daher Auto, Hersteller und Ausstattung relativ abstrakt und flexibel - es muss m.E. lediglich an einer Stelle entschieden werden, wer mit wem verheiratet werden darf (z.B.: Welche Ausstattungen können für ein Auto X von Hersteller Y verbaut werden). Das könnte dann z.B. im THersteller untergebracht werden (quasi ein Ausstattungsprofil) - die komplexere Logik, welche Ausstattung eine andere aussticht oder ersetzt, sollte dann wiederum ausgelagert werden.

Aber wie immer finde ich es im allgemeinen schwierig konkrete Vorschläge zu geben, wenn wir den genauen Anwendungsfall nicht kennen. Des Weiteren glaube ich, dass es unmöglich ist den Code aufzuräumen, wenn alleine die Anpassung der Listenverarbeitungen so lange dauern sollte wie der TE vermutet hat.

Und was genau meinst Du mit "... müsste man die Eigenschaft 'Ausstattung' jedes Mal casten ...", stehe grad auf dem Schlauch?

[Dejan Vu]

Zitat von alda:

Und was genau meinst Du mit "... müsste man die Eigenschaft 'Ausstattung' jedes Mal casten ...", stehe grad auf dem Schlauch?

z.B.:

Delphi-Quellcode:

Var
  car : TCar;
...
car := myCarContainer.GetCars(herstellerMercedes).First; 

if (car.Ausstattung as TMercedesausstattung).Sitzheizung.Status=AufStufe2 then
  CheckTemperature(my.Back.Lower);

...

habe ich konkrete Autoklassen, liefert 'GetCars' direkt den konkreten Typen, d.h. ich muss nirgens casten.

Delphi-Quellcode:

Var
  mercedes : TMercedes;

...
mercedes := myCarContainer.GetCars<TMercedes>.First;

if mercedes.Ausstattung.Sitzheizung.Status=AufStufe2 then
  CheckTemperature(my.Back.Lower);

Hier sind alle Typen konkret.

Grundsätzlich bevorzuge ich die 2.Möglichkeit (ohne Typecasting auskommen), wobei das nicht notwendigerweise 'pro Autoklasse' bedeutet, aber hier zufälligerweise so ist.

[Sir Rufo]

Ich frage mich inwieweit das Beispiel mit der realen Anforderung übereinstimmt oder ob hier nur einfach ein unglückliches Beispiel gewählt wurde und es somit zu falschen Annahmen und Schlußfolgerungen kommt.

[alda]

Ach so meinst Du das, ja da stimme ich Dir auch zu. Ich wollte auch nur einen Denkansporn liefern, über konkrete Implementierungen (Dein Beispiel wäre mir je nach Anwendungsfall auch schon wieder zu starr) kann dann disktutiert werden, wenn wir wissen was der TE alles mit dem Auto und vorallem den Ausstattungen machen können muss - oder hab ich das irgendwo überlesen?

Aber wie bereits erwähnt vermute ich, dass Änderungen eher schwierig sind für den TE - es handelt sich ja bestimmt auch um ein Programm das bereits produktiv im Einsatz ist und nicht mal eben umgestaltet werden kann?

Edit:

Zitat von Sir Rufo:

Ich frage mich inwieweit das Beispiel mit der realen Anforderung übereinstimmt oder ob hier nur einfach ein unglückliches Beispiel gewählt wurde und es somit zu falschen Annahmen und Schlußfolgerungen kommt.

Ja, genau das ist die Frage :>

[Martin W]

Danke euch sehr, vor allem das mit dem letzten Beitrag schaue ich mir näher an!

Viele Grüße!