Abstract oder überhaupt nicht?

[Muetze1]

Zitat:

Zitat von mkinzler

Aber nicht mit dem Konzept von abstrakten klassen.

Aber abstrakte Klassen sind doch im "normalen" Sprachumfang (vor Delphi 8) gar nicht möglich, nur abstrakte Methoden bis dahin. Ob es ab Delphi 8 möglich ist auch abstrakte Klassen in Delphi (nicht .NET oder C#) zu verwenden, weiss ich nicht.

[Jelly]

Zitat:

Zitat von Neutral General

Ja aber man könnte doch einfach abstracte Methoden weglassen und dem Programmierer überlassen ob er sie hinzufügt

Stichwort Polymorphismus. Klassen können bekanntlich Methoden vererben. Und Polymorphismus bedeutet das Gegenteil, d.h. in einer Basisklasse kann eine Methode aufgerufen werden, die erst in einem Nachfahren implementiert wird. Die Basisklasse braucht nicht genau zu wissen was der Nachfahre macht, aber sie muss die Methode als abstract deklarieren, da es sonst schon beim Compilieren knallt weil die Methode nicht bekannt ist.

[Hansa]

Der erste Gedanke ist manchmal der Beste ! Für eigene Zwecke ist Abstract Unfug. ABSTRACT ist für Komponenten-Entwickler gedacht. Die deklarieren etwas undefiniertes als abstract, um eben lediglich einen (sinnleeren) Namen zur Verfügung zu stellen und eine DCU auszuliefern. Du wirst wohl schon beim Testen gemerkt haben, daß es überall kracht, weil die Methoden eben undefiniert sind und man immer dran denken muß, sie mit Leben zu erfüllen. :???: Bei eigenen Komponenten usw. macht das kaum Sinn.

[OregonGhost]

Was Hänschen nicht lernt, lernt Hans nimmermehr... Warum sollte man auf gute Designprinzipien verzichten, nur weil man den Code nur selbst benutzt? Nachher gewöhnt man sich noch dran und kommt draußen in der weiten Welt nicht klar ;)
Wie Jelly und onlinekater sehr schön beschreiben, können abstrakte Methoden durchaus auch in der internen Entwicklung sinnvoll sein. Je umfangreicher ein Projekt ist, desto wichtiger ist es, dass alles ordentlich organisiert ist und nicht à la "die Funktion gibt's nicht, füg ich sie eben da ein, wo ich sie gerade brauche".
In vielen anderen Sprachen sind Klassen, die abstrakte Methoden enthalten, automatisch abstrakt und können nicht instanziiert geben. Da "kracht" es also nicht, sondern es gibt einen Kompilierfehler.

[Der_Unwissende]

Zitat:

Zitat von Neutral General

erm..*hust* :roll:

Es tut mir leid wenn es jetzt so rübergekommen ist das ich kein OOP könnte.. *hust*

Erstmal dazu, warum die Rechtfertigungen? Es ist doch nicht schlimm, wenn du die OOP noch nicht vollständig (und in allen Details) kennst. Abstraktion ist hier eines der wichtigsten Grundprinzipien und es dauert nun mal ein Weilchen, bis man hier die Vorteile verstanden hat. Ich seh immer wieder Beiträge, von Leuten die wirklich keine Ahnung von OOP haben und es ist vollkommen ok!
Wüßten alle alles, so wäre die DP leer, auch nicht das Wahre!

Die Grundlagen zu kennen und sie zu verstehen sind ausserdem noch zwei verschiedene Dinge. Es ist doch nur löblich, dass du nachfragst! Unwissenheit ist doch keine Schande, nichts an ihr zu Ändern schon!

Zitat:

Zitat von Hansa

Der erste Gedanke ist manchmal der Beste ! Für eigene Zwecke ist Abstract Unfug. ABSTRACT ist für Komponenten-Entwickler gedacht.

Sorry, aber das ist doch totaler Scheiß! Was sind denn die eigenen Zwecke? Also ich denke jeder Komponentenentwickler zählt das Entwickeln von Komponenten dazu.

So, ein wenig zum Thema abstrakte Methoden. Es gibt wirklich sehr viele Fälle, wo du eine Zusicherung durch abstrakte Methoden möchtest. Wie hier schon gesagt wurde (auch von dir) muss die Methode im verwendeten Nachfahren implementiert werden. Das Abstrakte hier ist, dass du nicht weißt wie. Damit ist die Implementierung ganz einfach austauschbar.
Ganz wichtig ist dieser Vorteil immer dann, wenn du an einem großen Projekt mitarbeitest. Da kommt es immer wieder vor, dass du eine Funktion brauchst, die aber noch gar nicht implementiert ist. Die eigentliche Anwendung, die programmiert werden soll, besteht i.d.R. aus sehr vielen verschiedenen Teilen. Du kennst vielleicht die Trennung MVC (Modell, View, Controller)? Natürlich gibt es noch ganz andere Einteilungen und jedes Problem kann aus kleinen Teilen bestehen. Nicht alle sind gleich schwer (beanspruchen gleich viel Zeit). Hast du eine abstrakte Methode, kannst du deine Klasse mit dieser Methode schon testen, ohne dass du in hier eine fertige Implementierung brauchst. Insbesondere kannst du hier auch einen Dummy schaffen und mit dem arbeiten. Ist irgendwann die echte Implementierung fertig, so kannst du die beiden einfach austauschen.

Gut, dass klingt nun auch nicht gerade nach "für eigene Zwecke", aber es ist nur eines von wirklich vielen Beispielen.
Eines dass dir auch für deine Zwecke begegnen könnte wäre das folgende:
Du möchtest einen Editor bauen. Und sagen wir mal (ganz kreativ), der soll plugin-fähig sein. Nun ja, jetzt hast du das Problem, dass deine Plugins nur funktionieren, wenn sie mitbekommen was im Editor passiert. Dass du für ein Plugin noch gar nicht weißt, was dieses mit dem Inhalt des Editors macht, dürfte auch klar sein, hier siehst du schon, dass es nicht ohne Abstraktion weiter gehen kann.
Sagen wir mal sehr stark vereinfacht, du möchtest, dass Plugins auf einen Tastendruck reagieren können. Dazu möchtest du die wissen lassen, wann eine Taste im Editor gedrückt wurde. Welche Möglichkeiten hast du also?
Klar, du könntest einfach Hooks benutzen, allerdings wird dann auch kein Entwickler (aus dir) Plugins bauen. Haut es also nicht raus.
Windows-Messages, auch nicht das Wahre, da muss schon wieder der Plugin-Entwickler umständlich drauf reagieren, selbes Problem.
Wie macht Delphi das gleich? Hm, hier gibt es Methodenzeiger (kannst ein OnKeyDown impelementieren). Dummerweise sollen aber alle Plugins mitbekommen, wenn die Taste gedrückt wurde. Natürlich kannst du jetzt ein Array von Methodenzeigern verwenden, aber dass ist halt nicht OOP.
In der OOP gibt es halt keine expliziten Zeiger.
Hier würdest du eher zum Observer-Pattern greifen. Dies ist recht einfach. Du hast ein Beobachtes Objekt (in diesem Fall der Editor) und beliebig viele Beobachter (die Plugins). Ein Beobachter kann sich beim Beobachteten für ein Ereignis anmelden. Tritt dieses Ereignis ein, so merkt es der Beobachtete und informiert alle registrierten Beobachter.
In dem Beispiel mit dem Editor könntest du dabei einfach eine abstrakte Klase nehmen, die Tastendrücke beobachtet.

Delphi-Quellcode:

type
  TTastenDruckBeobachter = class(TObject)
    public
      keyDown(const Key : Integer); virtual; abstract;
  end;

Wie du hier siehst, hat diese Klasse nur eine Methode und die ist abstrakt. Jedes deiner Plugins, dass von dieser Klasse erbt, muss die implementieren. Was für Plugins das sind, weißt du aber noch gar nicht, nur dass diese Methode vorhanden ist.
Ja, das ist auch alles was du jetzt beim beobachteten Objekt ausnutzt. Du schaffst einfach eine Methode, mit der sich Beobachter für Tastendrück anmelden können.

Delphi-Quellcode:

type
  TBeobachtestObjekt
    private
      FBeobachter : TObjectList;
    public 
      procedure registerTastenDruckBeobachter(beobachter : TTastenDruckBeobachter);

In dieser Methode merkst du dir einfach die Instanz, die sich anmeldet. Hier könntest du z.B. eine TObjectList verwenden. Natürlich sollte man auch die Möglichkeit des deregistrierens schaffen, aber hier erstmal egal.
So, jedes Plugin erbt nun von TTastendruckBeobachter und macht was auch immer es machen will, wenn eine Taste gedrückt wird. Welche Taste gedrückt wurde, steht ja in der Methode, wer die Methode aufruft und mit was für einem Parameter, weiß das Plugin wiederum nicht.
Tritt das Ereignis ein, so muss das Beobachtete Object nur noch die keyDown Methode von jedem gespeicherten Beobachter aufrufen. Als Argument wird natürlich die gedrückte Taste übergeben.

Ich denke so etwas kann einem auch mal in eigenem Code begegnen. Klar, in gewisser Weise schafft man hier eine Komponente, aber das geht in jedem Programm sehr sehr schnell.

Gruß Der Unwissende

[DGL-luke]

Zitat:

Aber abstrakte Klassen sind doch im "normalen" Sprachumfang (vor Delphi 8 ) gar nicht möglich

was ist jetzt falsch daran:

Delphi-Quellcode:

type
  TSomething = class abstract (TObject)
  private
    FElement: TSomethingElse
    
    function DoSomeThingGeneric;
    function YouImplementThatPlease; virtual; abstract;
  public
    constructor Create(genericparam: TType); virtual; abstract;
  end;

das ist eine astreine abstrakte klasse(ist natürlcih D2006, eventuell gibts das zuvor noch gar nicht). DoSomeThingGeneric ist bereits implementiert, und greift vielleicht auf FElement zu. Damit kann ich bestimmte Sachen bereits in dieser Basisiklasse implementieren. Die Folgeklassen sollten dann eben YouImplementThatPlease überschrieben.
Damit kann man auch, wenn man nur weiss, dass ein Objekt von TSomeThing abstammt, YouImplementThatPlease aufrufen (auf die Gefahr hin, dass man einen abstract error erntet).

So etwas ist nicht nur in Komponenten sinnvoll, sondern überall, wo man auf sachen zugreifen willl, von denen man zur Compiletime nicht genau weiss, wie sie später aussehen.
(Ich verwende so etwas im übrigen gerade)
@Der_Unwissende: Ja, PlugIns, das ist hier wohl das Stichwort.

[Hansa]

... und ein Geist wirds wohl nie lernen. :mrgreen: Man fängt nicht bei OOP mit TObject oder so was an (obwohl das oft zu sehen ist), sondern sucht sich einen geeigneten Vorfahrtyp aus und fügt neue Methoden, Felder usw. bei Bedarf hinzu. Besteht an der Stelle kein Bedarf, dann macht es keinen Sinn, sie schon bei Adam und Eva leer (also abstract) zu deklarieren, sondern eben erst ab der Hierarchiestufe, ab der sie benötigt werden. Im eigenen Programm weiß man normalerweise was wo gebraucht wird und braucht nicht unnötige Platzhalter mit rumzuschleppen. Sofern bereits klar ist, daß tatsächlich noch etwas fehlt, dann besteht auch an der Stelle kein direkter Zwang, abstract zu benutzen. Man kann den Prozedurrumpf auch leer lassen und später eben konkret besetzen. Wer ein begin end; einsparen will, der muß dann eben abstract benutzen.

[Luckie]

Zitat:

Zitat von Hansa

Man fängt nicht bei OOP mit TObject oder so was an (obwohl das oft zu sehen ist), sondern sucht sich einen geeigneten Vorfahrtyp aus und fügt neue Methoden, Felder usw. bei Bedarf hinzu.

Und wenn es keine Vorfahrenklasse gibt, die meinen Anforderungen entspricht? Dann sage ich dem Kunden: "Tut mir leid, kann ich nicht programmieren, der Hansa hat gesagt ich muss mir eine Vorfahrenklasse suchen, ich habe aber keine passenden gefunden. Und von TObject darf ich nicht ableiten, das hat mir der Hansa verboten."
Langsam sollte doch deutlich geworden sein, dass solche Pauschalisierungemn meist fehl am Platz sind. Das hat doch auch schon die goto-Diskussion gezeigt.

[Muetze1]

Zitat:

Zitat von DGL-luke

das ist eine astreine abstrakte klasse(ist natürlcih D2006, eventuell gibts das zuvor noch gar nicht).

Auf mehr als die nicht-Verfügbarkeit vor D2005, wollte ich nicht hinweisen. Es ist schlecht sowas hier grundsätzlich zu schreiben und nachher wird der Thread x-Mail wieder ausgegraben, weil Leute mit D7 und älter den Code nicht übersetzen können. War nur ein Hinweis - weil es wurde so allgemein genannt, als wenn es dies schon immer gibt und schon seit Jahren nutzbar in der Delphi Language vorkommt. Ansonsten hast du vollkommen Recht - dein Beispiel zeigt die abstrakten Klassen gut auf.

Zitat:

Zitat von Hansa

... und ein Geist wirds wohl nie lernen. :mrgreen: Man fängt nicht bei OOP mit TObject oder so was an (obwohl das oft zu sehen ist), sondern sucht sich einen geeigneten Vorfahrtyp aus und fügt neue Methoden, Felder usw. bei Bedarf hinzu. Besteht an der Stelle kein Bedarf, dann macht es keinen Sinn, sie schon bei Adam und Eva leer (also abstract) zu deklarieren, sondern eben erst ab der Hierarchiestufe, ab der sie benötigt werden. Im eigenen Programm weiß man normalerweise was wo gebraucht wird und braucht nicht unnötige Platzhalter mit rumzuschleppen.

Ich habe eine Methode Geschlecht, welche mir das Geschlecht zurück liefert. Folgende Möglichkeiten:

1. Nun müsste ich an einer Stelle wo ich dies allgemein abfragen will, jeweils Adam und auch Eva kennen und testen, habe ich nun eine Eva oder eine Adam Instanz und dann auf diese Casten, um dann die Methode aufzurufen um das Geschlecht zu erhalten.
2. Ich definiere mir eine virtuelle Funktion im Vorfahrtyp von Adam und Eva. Die muss ich hier auch gleich implementieren - aber was gebe ich zurück? Nichts? Oder gebe ich nun männlich oder weiblich zurück? Was nur? Ich grübel noch ein paar Jahre ...
3. Nochmal das gleiche wie in 2.: Ich füge eine virtuelle Methode Geschlecht ein. Ich habe mich auf ein "Standardgeschlecht" geeinigt: männlich. Nun hat aber der Entwickler von Eva geschlafen und die virtuelle Methode nicht überschrieben und schon bekomme ich bei Adam und Eva als Geschlecht männlich zurück geliefert.
4. Ich definiere eine abstrakte Methode Geschlecht in der Basisklasse von Adam und Eva. Dadurch kann ich das Geschlecht auch schon in der Basisklasse abfragen und benutzen in anderen Methoden der Klasse und ich kann mir sicher sein, dass die späteren Leute auch immer ihr richtiges Geschlecht angeben, da eine abgeleitete Klasse die Methode implementieren muss.

Was ist davon nun am besten? Für mich kommt nur 4. in Frage. Ich kann sicher sein, dass ich die richtige Information bekomme und ich kann das Geschlecht ganz abstrakt abfragen. Programmierfehler wie falsche Informationen oder schlimmer noch vergessene Implementation durch vergessene Überschreibungen von Methoden, fallen sofort auf (EAbstractException). Somit habe ich doch die meiste Sicherheit bei dem 4. Punkt.

Die Exception zu den nicht implementierten abstrakten Methoden ist ein Hinweis zur Entwicklung und keiner wird eine abstrakte Methode einfügen und dann das Programm keine 5 Minuten später ausliefern, so dass ein Kunde das bekommt. Durch das QM sollte vorher mindestens ein paar Tests durchlaufen werden, wo genau solche Meldungen auftreten und den Misstand im Code aufzeigen.

[Der_Unwissende]

Zitat:

Zitat von Hansa

Man fängt nicht bei OOP mit TObject oder so was an (obwohl das oft zu sehen ist)

Stimmt, denn OOP hat nichts mit Delphi zu tun. Das liegt daran, dass die OOP ein Konzept ist und Delphi eine Programmiersprache. Wie man die Ideen der OOP umsetzt ist nirgends festgeschrieben. Wie kommt man doch gleich an eine geeignete Vorfahrklasse ran? Meinst du die sind gänzlich ohne Abstrakte Methoden entstanden? (s. TStream, TStrings, und viele viele mehr).

Zitat:

Zitat von Hansa

Im eigenen Programm weiß man normalerweise was wo gebraucht wird und braucht nicht unnötige Platzhalter mit rumzuschleppen.

Wow, wie klein sind denn deine Programme? Also irgendwie stehen bei mir (und allen Kunden für die ich etwas entwickle) die Anforderungen nicht zu beginn fest. Um es klar zu stellen, die Kunden haben einen Wunsch, es ist also ihr Programm, sie sagen mir was sie wollen, also ist es ihr Programm! Ich setzt es nur in Code um.
Jedenfalls ändern sich da mal Ansprüche, ein paar Dinge sollen dann doch rein oder eben nicht und wenn's gut läuft, möchte man vielleicht etwas Ähnliches. Gerade wenn du hier versuchst eine GUI gleich zu halten (Wiedererkennung ist wichtig), kommt es schnell dazu, dass du gerne auf OOP (und damit abstrakte Methoden) zurückgreifst.

Zitat:

Zitat von Hansa

Wer ein begin end; einsparen will, der muß dann eben abstract benutzen.

Wow, begin und end sparen, ich glaube du hast den Zweck von OOP (und abstrakter Methoden) völlig verstanden! Nicht schlecht.

@ALLE OPs, könnte in diesem Thread ein Warnschild angebracht werden, dass hier Meinungen geäussert werden, die sich kein Anfänger anschauen sollte! Ich meine es muss ja nicht auf den konkreten Beitrag hingewiesen werden, aber wenn jmd. so was liest und das dann auch noch glaubt!!! Das kann man doch gar nicht wieder gut machen!

[Edit]
Begriff korrigiert
[/Edit]