Interfaces + Factorys

[stahli]

Ich habe länger gebraucht, um das Konzept und die Benutzung von Interfaces in Delphi zu verstehen.

Es gibt zwar einige Erklärungen und Beispiele, die waren jedoch nicht immer für Neulinge in dem Themenbereich geeignet.

Daher habe ich hier einmal versucht, meine Erkenntnisse und bisherigen Erfahrungen zusammenzufassen.
Die Videos sind nicht hochprofessionell, aber vielleicht helfen sie einigen Interessierten, die Interfaces in Delphi schneller zu verstehen und anwenden zu können...


Die Erläuterungen habe ich in 3 Blöcke aufgeteilt:

Einige Basics zu Interfaces in Delphi.
http://youtu.be/MEX1836SvgE

Etwas detaillierte Infos und Anwendungsbeispiele.
http://youtu.be/IyvqZAUSJGY

Verbergen der Klassen und Arbeiten nur mit Interfaces.
http://youtu.be/NcbIV0SUFJs


Wenn ich etwas fehlerhaft oder unvollständig erläutert habe, dann können wir das hier gern richtig stellen...

[alda]

Ich widerspreche gleich mal der Aussage in Video Teil 3, ab Minute 14:00, wenn ich darf .
Der "Aufwand" den Du ansprichst ist lediglich ein Manko der IDE. Die Vorteile kommen Dir immer dann zu Gute, wenn Du Implementierungen temporär (mehrfach) austauschen musst. Da wirst Du also dann drauf stoßen, wenn Du alles akribisch testest.

Es würde anderen mit Sicherheit auch sehr helfen, wenn Du in diesem Zuge (langfristig) auch das Thema Testing (Testdriven vs. nicht Testdriven vs. keine Interfaces) mit aufnimmst.

Weiter so und noch viel Spaß

[Mavarik]

hmm..

Zu Video 1:

Klar Funktioniert das... Aber so etwas wäre auch so gegangen:

Delphi-Quellcode:

type
   TBaseReader = class
     public
       Procedre Read;virtual;Abstract;
   end;

   TXMLReader = class(TBaseReader)
     public
       Procedure Read;Virtual;Override;
   end;

   TCSVReader = class(TBaseReader)
     public
       Procedure Read;Virtual;Override;
   end;

implementation

Procedure Read(Reader : TBaseReader);
begin
  Reader.Read;
end;


procedure TForm31.FormCreate(Sender: TObject);
var
 R1 : TXMLReader;
 R2 : TCSVReader;
begin
  R1 := TXMLReader.Create;
  R2 := TCSVReader.Create;
  Read(R1);
  Read(R2);
  R1.Free;
  R2.Free;
end;

Schau Dir mal das an...

Mavarik

[Dejan Vu]

Abstrakte Klassen ohne Funktionalität sind den Interfaces ähnlich, nur das sie eben Delphi sind und bleiben. Ein Interface kommt von irgendwo her, definiert einen Vertrag und wenn deine Implementierung den erfüllt, kannst Du eine Delphi-Klasse an ein PHP-Skript hängen, oder eine C-Implementierung deines Interfaces in deinem Programm. Mach das mal mit deinen abstrakten Klassen.

Als Anwender bzw. 'Implementierer' weiß ich nicht, ob die abstrakte Klasse nicht doch eine Grundfunktionalität implementiert oder implementieren wird. Bei einem Interface kann ich mir 100% sicher sein, das alles, was passiert, in meinem Code stattfindet.

[OlafSt]

Es geht doch auch gar nicht darum, ob und wie man das mit Klassen hätte machen können. Solange man innerhalb von Delphi unterwegs ist, kann man alles mit Klassen erschießen und kann auf Interfaces mehr oder weniger verzichten.

Aber das ist nicht der Punkt.

stahlis Videos dienen dazu, Typen wie mir überhaupt begreiflich zu machen, wie Interfaces und das ganze Drumherum in Delphi überhaupt funktioniert. Ich mußte mich erst als totaler Nixblicker outen und einen Thread erstellen Mir hat das Video Nummer 1 klar gezeigt, das ich die Basics nun verstanden habe und die beiden anderen Videos zeigen praktische Anwendungen auf extrem niedrigen Niveau - aber genau dieses Niveau muß man haben. Denn nur dann kapiert auch einer, der es gerade erst vor 5 Minuten gerafft hat, auch wirklich.

Ich hab auch gleich einen Kandidaten gefunden, der sich diese Videos mal reinziehen sollte.

[Mavarik]

Zitat von Dejan Vu:

Abstrakte Klassen ohne Funktionalität sind den Interfaces ähnlich, nur das sie eben Delphi sind und bleiben. Ein Interface kommt von irgendwo her, definiert einen Vertrag und wenn deine Implementierung den erfüllt, kannst Du eine Delphi-Klasse an ein PHP-Skript hängen, oder eine C-Implementierung deines Interfaces in deinem Programm. Mach das mal mit deinen abstrakten Klassen.

Darum geht es doch gar nicht... Ich finde nur es ist ein schlecht Beispiel um Interfaces zu erklären.
Der Programmieren sollte doch auf den 1. Blick sehen warum er damit arbeiten soll und nicht so "altklug" wie ich kontern können : na nana na naaaa naaaaaa... Kann ich auch ohne Interfaces...
So ist das keine Motivation.

Zitat von OlafSt:

Ich hab auch gleich einen Kandidaten gefunden, der sich diese Videos mal reinziehen sollte.

Dann schau Dir lieber mal das Video an!

Nach diesem Video habe ich mich SOFORT auf Interfaces eingestellt... Genau aus den 2 wichtigen Gründen.

- Entkoppelung
- Referenzzählung
- Shoot & Forget Code

Somit schlage ich zwei Fliegen mit einer Klappe... Meine "objecte" sind ARC kompatible und mein Code ist unabängig von einander.

Zum Beispiel wenn ich Funktionalitäten an und abschalten will...

Delphi-Quellcode:

var
  NeueRoutine : INeueRoutine;
begin
  NeueRoutine := GlobalClassManager.GetClass<INeueRoutine>;
  if Assigned(NeueRoutine) 
    then NeueRoutine.MachwasTolles
    else MyMessage('Funktionalität in der Lite Version nicht enthalten');
end;

Jetzt kann ich entweder per Programmlogik das Interface nicht am Pool registrieren... oder die Unit ist ggf. gar
nicht im Projekt enthalten, denn in der Unit steht:

Delphi-Quellcode:

Initialization
  GlobalClassManager.RegisterClass<INeueRoutine,TNeueRoutine>;

oder eben per Logic

Delphi-Quellcode:

Initialization
  if Lizenz.Can_NeueRoutine then
    GlobalClassManager.RegisterClass<INeueRoutine,TNeueRoutine>;

Für die Implementation gibt es 2 Wege... (Wahrscheinlich hunderte)

Entweder

Delphi-Quellcode:

Unit neueRoutine;

Interface
type
   INeueRoutine = Interface
     Procedure MachWasTolles;
   end;
Implementation
type
   TNeueRoutine = Class(TInterfacedObject,INeueRoutine)
                   private
                     Procedure MachWasTolles;
                  end;   
...

So mach Ich es... Bedeutet jedoch auch wenn ich das Interface nicht am Pool Registriert habe... Die Unit ist wegen dem Interface immer dabei.

oder

Delphi-Quellcode:

Unit MyInterfaces;

Interface

type
   INeueRoutine = Interface
     Procedure MachWasTolles;
   end;

Implementation

end.

// ---------------------------------------

Unit NeueRoutine;

Interface
// NIX
Implementation

Uses ClassManager,MyInterfaces;

type
   TNeueRoutine = Class(TInterfacedObject,INeueRoutine)
                   private
                     Procedure MachWasTolles;
                  end;   
...

Der Vorteil vom 1. Weg liegt auf der Hand... Ich kann dem Kunden einfach einen neuen Registrierungscode zusenden und schon kann er das Programmteil nutzen. (InApp-Käufe)

Der 2. Weg macht die Exe kürzer (Wenn das "neue" nicht dabei ist).

Naja und auf jeden Fall kann ich die Klasse unter ARC (Mobile) genauso verwenden wie unter OSX/Windows...

3. Grund Shoot & Forget

Delphi-Quellcode:

Var
  AndererCode : IAndererCode;
begin
  AndererCode.MachwasUndWegDamit; // Class Function Return IAndererCode;
end;

Mavarik

[stahli]

@Mavarik

Ich bin ein Freund der kleinen Schritte und wollte zunächst einmal aufzeigen, wie und wozu man von der bisherigen Arbeit mit normalen Klassen zu Interfaces wechseln kann.

Dependency Injection und das Spring Framework sind sicher nicht hilfreich, um Interface-Neulingen ein Grundverständnis zu vermitteln.

Es ist ja nicht ausgeschlossen, dass man mit einiger Erfahrung dann den Schritt gehen will, aber das Thema ist hier deutlich verfrüht (und wäre besser in einem eigenen Thread aufgehoben).

[Dejan Vu]

Zitat von Mavarik:

Zitat von Dejan Vu:

...Mach das mal mit deinen abstrakten Klassen.

Darum geht es doch gar nicht...

Äh doch.

Grundkurs Taschenrechner:
Lehrer: "Wir tippen [1] [+] [1] [=] und haben das Ergebnis"
Schüler: "Wieso tippen? Das rechne ich im Kopf aus".

G-r-u-n-d-k-u-r-s

... Verstehst Du?

[Mavarik]

Zitat von Dejan Vu:

G-r-u-n-d-k-u-r-s

... Verstehst Du?

Motivation
... Verstehst Du?

Ein G-r-u-n-d-k-u-r-s der mir sagt..
- boh viel tipperei
- boh aufwending

Und dann eigentlich kein Lernziel nennt...

Mavarik

[Stevie]

Zitat von Mavarik:

*snip*

Argh, Service Locator Antipattern. Den Code, den Nick da irgendwann mal gezeigt hat, muss ich den Leuten heute noch immer wieder austreiben.

Bitte bitte. Auch wenns auf den ersten Blick clever auschaut, seine Software so zu entkoppeln, macht man es auf lange Sicht nur viel schlimmer.
Und außerdem ist das keine Dependency Injection. Du injektest da nix, sondern greifst über einen SL auf eine an anderer Stelle registrierte Instanz zu.