Interfaces + Factorys

[Sir Rufo]

Zitat von DeddyH:

Wofür braucht man technisch gesehen überhaupt Sichtbarkeiten?

Bei einer public Property werden die Getter/Setter nur aus kosmetischen Gründen nicht public deklariert, eben aus dem gleichen Grund warum die Codevervollständigung bei Interfaces die Getter/Setter nicht anzeigt.

[stahli]

Jetzt muss ich noch etwas zum Video 2 + 3 nachfragen (Stand hochgeladenes Projekt vom ersten Beitrag).

Ich habe zwei Fahrzeuge, die einen Motor haben (Auto und Boot).
Jetzt könnte man sich noch ein Elektrofahrrad einführen, hätte also 3 Klassen mit einem Motor.

Wenn IMotor StarteMotor und Tanken implementiert, müssen das die 3 Klassen auch unmittelbar tun.
Auto und Boot könnten aber mit einem Benzin-, Diesel- oder Elektromotor ausgestattet werden.

Wäre es somit nicht vielleicht sinnvoll, eine Klasse TMotor UND dazugehörige Schnittstelle IMotor einzuführen?

Dann könnten die Fahrzeuge so aussehen:

Bsp. Auto:

Delphi-Quellcode:

  TAuto = class(TInterfacedObject, IHasMotor)
  private
    FMotor: IMotor;
      FAnzahlRaeder: Integer;
      procedure SetAnzahlRaeder(const Value: Integer);
      procedure Fahre;
    //procedure StarteMotor;
    //procedure Tanken;
  public
    property Motor: IMotor read get_Motor write set_Motor;
      property AnzahlRaeder: Integer read FAnzahlRaeder write SetAnzahlRaeder;
  end;

Die Interfaces könnten dann so aussehen:

Delphi-Quellcode:

  IMotor = interface
    procedure StarteMotor;
    procedure Tanken;
  end;

  IHasMotor = interface
    function get_Motor: IMotor;
    procedure set_Motor(const Value: IMotor);
    property Motor: IMotor read get_Motor write set_Motor;
  end;

So könnte man dem Auto verschiedene Motoren hinzufügen.
Allerdings könnte ein Elektromotor dann nicht tanken sondern man würde die Batterie aufladen.
Ich muss also zur Laufzeit ggf. immer prüfen, welcher Motor eingebaut ist und ob überhaupt einer existiert.

Klar, man kann der Fabrik schon sagen: Gib mir ein Auto mit Elektromotor zurück, aber zur Laufzeit weiß man ja dann dennoch nicht, was man nun genau vorliegen hat.

An der Stelle komme ich nicht ganz weiter.
Wie würdet Ihr damit umgehen? (Aber bitte nicht auf das Spring-Framework o.ä. verweisen, damit das hier nachvollziehbar bleibt.)

[Sir Rufo]

Mal ganz weg von der Programmierung, aber das Betanken an und für sich im Sinne von "fülle das nach, damit der Motor arbeiten kann" ist doch für jeden Motor in diesem Sinne gleich.

Das was man tankt muss zum Motor passen, aber "Tanken" müssen sie alle (vor allem weil "Tanken" das Befüllen eines "Tanks" -> Vorratsbehälters beschreibt ohne dabei das Tankgut oder den Tank irgendwie einzuschränken).

Also ist Tanken als Methode völlig ok (wenn das, was man tankt in diesem Kontext keine Rolle spielt bzw. spielen muss).

Einen konkreten Dieselmotor würde man dann mit einer Verbindung zu einem Diesel-Lieferanten erzeugen, den Benzinmotor mit einer Verbindung zu einem Benzin-Lieferanten und den Elektromotor mit einem Strom-Lieferanten.

[stahli]

Den Unterschied zwischen Tanken und Aufladen habe ich nur exemplarisch ins Spiel gebracht.
Es kann ja in echten Fällen möglicherweise Unterschiede geben, die für den weiteren Verlauf relevant sind.

Das ERZEUGEN eines Autos mit einem bestimmten Motor sehe ich nicht als Problem.
Aber später müsste ich immer prüfen:
- Kann das Objekt, das ich hier habe einem Motor haben?
- Hat es tatsächlich einen Motor?
- Kann ich damit tanken und was oder an die Steckdose?

Würdest Du also meine zwei Schnittstellen IMotor (die dann eine tatsächliche Motorinstanz representiert) und eine Schnittstelle IHasMotor (oder eigentlich besser: IKannMotorHaben) (die einem Auto und Boot hinzugefügt wird, nicht aber einem Fahrrad oder Vogel) sinnvoll finden?

[Sir Rufo]

Zitat von stahli:

Den Unterschied zwischen Tanken und Aufladen habe ich nur exemplarisch ins Spiel gebracht.
Es kann ja in echten Fällen möglicherweise Unterschiede geben, die für den weiteren Verlauf relevant sind.

Das ERZEUGEN eines Autos mit einem bestimmten Motor sehe ich nicht als Problem.
Aber später müsste ich immer prüfen:
- Kann das Objekt, das ich hier habe einem Motor haben?
- Hat es tatsächlich einen Motor?
- Kann ich damit tanken und was oder an die Steckdose?

Würdest Du also meine zwei Schnittstellen IMotor (die dann eine tatsächliche Motorinstanz representiert) und eine Schnittstelle IHasMotor (oder eigentlich besser: IKannMotorHaben) (die einem Auto und Boot hinzugefügt wird, nicht aber einem Fahrrad oder Vogel) sinnvoll finden?

Das ist immer genau das Problem an diesen "an den Haaren herbeigezogenen" Beispielen, wo man Enten, Fahrräder und Autos irgendwie gleich behandeln will. Man kommt nicht so richtig ins vorne und stösst dabei auch eben auf die besagten Probleme.

Sinnvoller erscheint mir etwas wie

Delphi-Quellcode:

IMotorBetrieben = interface
  funtion GetMotor : IMotor;
end;

IMobil = interface
  procedure BewegeZu( Ort : TPoint );
end;

IKannSprechen = interface
  procedure Sage( AText : string );
end;

Mit Supports fragt man dann ab, ob dieses oder jenes Interface unterstützt wird und führt das dann aus:

Delphi-Quellcode:

procedure Sage( AText : string; AContext : IInterface );
var
  LSprecher : IKannSprechen;
begin
  if Supports( AContext, IKannSprechen, LSprecher ) then
    LSprecher.Sage( AText );
end;

[stahli]

Ok, super!

Das IMotorBetrieben ist eine bessere Bezeichnung als IHasMotor. Aber konzeptionell meinte ich das Gleiche.

Allerdings reicht Supports(aContext, IMotorBetrieben) für einen Zugriff auf den Motor noch nicht ganz aus, weil der ja nil sein könnte.
Also muss dazu ggf. nochmal eine Prüfung her.

Wenn man ganz mutig denkt, könnte ein späterer Fluxkompensator natürlich zu unserer Motor-Schnittstelle nicht mehr kompatibel sein.
Aber ok, das muss man wohl akzeptieren und in 20 Jahren die Schnittstellen ggf. nochmal überarbeiten.


Die Enten und Fahrzeuge finde ich aber im Zusammenhang mit Schnittstellenbeispielen dennoch nicht schlecht, da man sieht, dass völlig unterschiedliche Klassen (ohne direkte gemeinsame Basisklasse) die gleichen Schnittstellen bedienen können.

[Sir Rufo]

Wenn nil zulässig ist, dann hat man das NULL-Pattern oder man wirft idealerweise ASAP eine Exception (Guard).

Was richtig ist hängt vom Gesamtkontext ab und kann pauschal nicht beantwortet werden. Ich würde das aber zunächst völlig herauslassen und eben immer bei IMotorBetrieben einen Motor voraussetzen.

[Stevie]

Bei einigen Aktionen solltest du überlegen, ob sie wirklich zu der Klasse gehören.

Zum Beispiel die Methode Tanken gehört sicherlich nicht in die Klasse Motor oder Auto oder Boot.
Diese Klassen/Interfaces sind nicht die Akteure, sondern die Argumente für die Aktion betanken, welche ein IBetankbar Interface oder sowas haben.

[Sir Rufo]

Man kann das mit dem Motor auch anders darstellen

Delphi-Quellcode:

IBetriebsstoffQuelle = interface
  function GetBetriebsstoffArt : Integer;
  procedure Entnehme( AMenge : Single );
end;

IMotor = interface
  procedure Tanken( AQuelle : IBetriebsstoffQuelle );
end;

Jetzt kann der Motor prüfen, ob die Quelle den richtigen Betriebsstoff liefert und sich die benötigte Menge entnehmen.