Abstract oder überhaupt nicht?

[Neutral General]

Hi,

Ich hatte gestern das erste mal wirklich etwas mit abstracten Methoden zu tun :)
Ok ich hab sie auch schon zu spüren bekommen als ich versucht hatte mit einem TStream Daten auszulesen aber als es da gekracht hab, hat mich das eigentlich nur geärgert und ich hab nicht weiter drüber nachgedacht :mrgreen:

Naja ich frage mich jetzt:
Was ist der Vorteil von abstracten Methoden?

Man könnte die Methode doch in der Basisklasse einfach weglassen.. Die Nachfolger könnten sie doch einfach so hinzufügen und sie hätten sich das Length('override;') Zeichen gespart :mrgreen:
Das einzige etwas sinnvolle was mir einfällt ist das der Programmierer mehr oder weniger gezwungen ist abstracte Mehtoden in der Nachfolgeklasse auszufüllen weil es ansonsten halt kracht wenn man sie aufruft...

Wenn man will das die Methode in der Basisklasse leer ist dann könnte man sie doch theoretisch auch einfach virtual machen und sie leer lassen. Dann würde es wenigstens nicht krachen wenn man sie aufruft...

Also was ist jetzt der Vorteil?

Gruß
Neutral General

[JasonDX]

Zitat:

Zitat von Neutral General

Wenn man will das die Methode in der Basisklasse leer ist dann könnte man sie doch theoretisch auch einfach virtual machen und sie leer lassen. Dann würde es wenigstens nicht krachen wenn man sie aufruft...

Dass es kracht ist ein Vorteil. Das bedeutet naemlich, dass man bei der Implementierung etwas falsch gemacht hat.
Stell dir mal vor:
TStream deklariert Read(...) als virtuell, und implementiert eine leere Funktion.
TFileStream implementiert aber kein Read(...)
Wenn ich nun TFileStream.Read aufrufe, dann passiert nix - und es funktioniert auch nix. Durch abstract wird man (wie du erkannt hast) gezwungen, die Methode entweder zu deklarieren, oder weiterhin als abstract beizubehalten - durch denentsprechende Deklaration.
Die Fehlermeldung, die du erhaelst, zeigt dir, dass etwas nicht stimmt, und du kannst das Problem schnell lokalisieren. Wenn aber kein Fehler auftritt, und das Programm einfach nicht funktioniert (weil eben bspw. keine Daten aus TFileStream gelesen werden), dann sitzt man schon mal ein paar Stunden/Tage an der Fehlersuche ;)

greetz
Mike

[Neutral General]

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

[mkinzler]

Du bist gleichzeitig auf eine Besonderheit von Delphi gestossen, das nämlich das Anlegen von Instanzen von abstrakten Klassen erlaubt.
Abstrakte Methoden sind als Verpflichtung von abgeleiteten Klassen zur Implemnetierung zu verstehen. So kann eine übergeordnete Klasse eine Methode bereitstellen, welche dann von verschiedenenabgeleiteten Klassen verschieden implemnetiert wird.

[Dax]

Zitat:

Zitat von Neutral General

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

Wo bitte wäre dann der Sinn in der Basisklasse? :gruebel:

TStream und seine Methoden sind deshalb abstrakt, weil sie ein Interface darstellen sollen, mit dem man auf alle Streams zugreifen kann. Kuck dir mal die Indys an, die liefern in ihren Ereignissen auch TStreams, nicht TMemoryStreams - obwohl sie die intern benutzen.

[mkinzler]

@Neutral General: Lies dich mal in sie Grundlagen der OOP ein.

[TBx]

Das weglassen hätte große Nachteile.

Ich schreibe meine Daten z.B. gerne wahlweise in einen TMemorstream oder in einen TFilestream.

Meine Variable deklariere ich als TStream, weise Ihr aber entweder ein TFilestream oder ein TMemorystream zu.

Rufe ich nun das Read bzw. das Write der Variablen auf, wird automatisch die richtige Funktion/Prozedur, nämlich die der entsprechenden Childklasse angesprochen.

Hätte man Read und Write in der Basisklasse TStream nicht deklariert, so wäre das nicht möglich.

abstract wird eigentlich immer dann verwendet, wenn man einer Gruppe von Klassen eine Methode mitgeben möchte, die zwar bei allen Nachfahren das selbe Ziel hat (z.B.: schreiben und lesen) aber auf ganz unterschiedlichen Wegen funktionieren.

Hoffe, das bringt ein kleines bißchen licht ins Dunkel.

Gruß

onlinekater
[such]wo it er, der rote Katen...[/such]

[Neutral General]

Zitat:

Zitat von mkinzler

@Neutral General: Lies dich mal in sie Grundlagen der OOP ein.

erm..*hust* :roll:

Es tut mir leid wenn es jetzt so rübergekommen ist das ich kein OOP könnte.. *hust*
Ehhm.. Das war einfach nur eine Frage die mich beschäftigt hat. Weil man abstract ja eigentlich nicht brauch wenn man seine Klasse nur selbst verwendet.. Also was ich sagen will: Ich kann euch beruhigen ich bin mit den Grundlagen von OOP vertraut --- ___ ---

:roll: :roll: :roll: :wall:

EDIT: Thx ich denke ich habe jetzt den Sinn von abstract verstanden.. Hatte mir das vorher auch in etwa so gedacht ;)

[TBx]

also ich brauche abstract in meinen selbstverwalteten Klassen.
Eben aus den Gründen, die ich in meinem letzten Beitrag aufgezeigt habe.

Gruß

onlinekater

[mkinzler]

Zitat:

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

Ich kann dich beruhigen, so ist es nicht rübergekommen.

Zitat:

Das war einfach nur eine Frage die mich beschäftigt hat. Weil man abstract ja eigentlich nicht brauch wenn man seine Klasse nur selbst verwendet.

Dann barucht man es vielleicht nicht unbedingt, ich würde es aber trotzdem verwenden.

Zitat:

Ich kann euch beruhigen ich bin mit den Grundlagen von OOP vertraut --- ___ ---

Aber nicht mit dem Konzept von abstrakten klassen.

[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]

[Jelly]

Besser als Muetze1 hätt ichs bestimmt nicht erklären können :thumb:

[Neutral General]

Zitat:

Zitat von 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!

Ja so sollte das nicht rüberkommen. Also mir ist auch klar das ich kein OOP-Gott bin und auch noch einiges lernen kann/muss. Aber das hat sich halt so angehört als ob ich noch nie was von OOP gehört hätte :|

Naja aber egal.. Also das ist schon ziemlich interessant was hier geschrieben wurde :)
Ich denke ich probier das mit den abstracten Klassen mal aus... Dann lern ichs am besten und ich denke ich werde dabei auch verstehn wofür man sie braucht (bzw ich weiß es ja jetzt schon aber ich würde es halt richtig erfahren).
Hat jemand vielleicht ne kreative Idee für ein kleines Projekt indem man abstracte Klassen und Methoden braucht?

Gruß
Neutral General

[xaromz]

Hallo,

Zitat:

Zitat von Neutral General

Hat jemand vielleicht ne kreative Idee für ein kleines Projekt indem man abstracte Klassen und Methoden braucht?

da hätte ich eine Idee:
Bau Dir ein Programm, mit dem Du geometrische Objekte zeichnen kannst (Kreise, Rechtecke, Linien, Polygone, WasAuchImmer). Jede geometrische Form ist eine eigene Klasse, wobei jede Klasse bestimmte Methoden implementieren muss, wie z. B. Paint, Save, Load, Change usw.
Da kannst Du Dir eine abstrakte Basisklasse schreiben und darauf aufbauend beliebig viele geometrischen Objekte erschaffen.
Bei einem neuen Element musst Du nur eine Instanz der jeweiligen Klasse erzeugen, und kannst dann in einer Schleife alle Objekte mit dem gleichen Aufruf zeichnen.

Übrigens, um hier auch Hansa klarzumachen, dass man abstract durchaus benutzen kann, genau so wie hier beschrieben ist die Klassenhierarchie meiner SVG-Implementation aufgebaut.

Gruß
xaromz

[Hansa]

Hier steht die Frage :

Zitat:

Zitat von Neutral General

Was ist der Vorteil von abstracten Methoden?...

Antwort habe ich noch keine gesehen. 8)

[mkinzler]

Zitat:

Antwort habe ich noch keine gesehen. Cool

Dann würde ich die ganzen Antworten nocheinmal durchlesen.

[JasonDX]

Zitat:

Zitat von Hansa

Hier steht die Frage :

Zitat:

Zitat von Neutral General

Was ist der Vorteil von abstracten Methoden?...

Antwort habe ich noch keine gesehen. 8)

Dann solltest du eine Brille aufsetzen, Monitor anschalten, lesen lernen, was auch immer dich davon abgehalten hat, den Inhalt mancher Posts in diesem Thread zu verstehen. :roll:
Eine dementsprechende Diskussion gabs bereits mal: *klick*

greetz
Mike

[Hansa]

Zitat:

Zitat von JasonDX

...Monitor anschalten, lesen lernen, was auch immer dich davon abgehalten hat, den Inhalt mancher Posts in diesem Thread zu verstehen.

Echt schön. :-D Aber wo ist jetzt die Antwort ? Es fehlt die Begründung, undefinierte Sachen zu benutzen.

[JasonDX]

Zitat:

Zitat von Hansa

Echt schön. :-D Aber wo ist jetzt die Antwort ? Es fehlt die Begründung, undefinierte Sachen zu benutzen.

Ok, mal ein einfaches Beispiel, extra fuer dich:
Gegeben sei die Basisklasse TStream, welche diverse Methoden deklariert, wie bspw. Read, Write, Close ect.
Es gibt dann diverse Klassen, die von TStream abgeleitet sind, und die Methoden implementieren.
So, TStream kann jetzt diese Methoden

1. als abstrakte Methode deklarieren
2. mit virtual kennzeichnen und eine leere Methode ranpflanzen

Und nun folgendes Szenario:
Ich will Daten aus einem beliebigen Stream laden, und verwende dazu logisch meine Basisklasse.

Delphi-Quellcode:

procedure LoadData(Data: Stream);
begin
  //blubbdibla
end;

Nun beobachten wir folgenden Fall:

Delphi-Quellcode:

var
  MyData: TStream;
begin
  MyData := TStream.Create;
  LoadData(MyData);
end;

Kompiliert einwandfrei.
Wenn wir die erste Moeglichkeit nehmen, also abstrakte Methoden in TStream deklariert haben, dann kriegen wir eine Exception um die Ohren geschmissen: Achtung, du baust da richtig Mist. Stimmt auch.
Wenn wir die zweite Moeglichkeit nehmen, also die virtuellen Methoden verwenden, dann kriegen wir keine Exceptions. Ok, das Programm laeuft vielleicht ohne Exceptions zu ende, aber funktionieren tuts trotzdem nicht - Es werden keine Daten geladen. Und da ich keine Fehlermeldung kriege, dann kann ich mich mal ein paar Stunden dransetzen, um den Fehler zu suchen um dann zu merken, dass abstract doch ned so bloed gewesen waere.
Damit sollte der Vorteil wohl offensichtlich sein, und wenn du jetzt nochmal den Thread durchliest, dann wirst du sehen, dass es darin genuegend dementsprechende Beispiele gegeben hat, die dir genau das selbe sagen.

greetz
Mike

[Muetze1]

Zitat:

Zitat von Hansa

Echt schön. :-D Aber wo ist jetzt die Antwort ? Es fehlt die Begründung, undefinierte Sachen zu benutzen.

1. Du kannst die Antwort aus meinem Beispiel nicht rauslesen oder bist du einfach nur lern-resistent? Du siehst kein Sinn und keine Vorteile bei der 4. Lösung zu dem oben genannten Beispielproblem? Für dich sieht das alles gleich aus mit 0 Vorteilen?

Gegenfrage: wozu schreibe ich denn hier? Bisher war jede Diskussion um abstrakte Methoden/Klassen mit dir immer auf diesem Prinzip abgelaufen. Man erklärt dir die Vorteile und Beispiel wo man dieses sprachliche Mittel einsetzen kann mit Vorteilen und du schreibst immer nur einfach, dass du keine Vorteile siehst und das es Bockmist ist. Wieviele Diskussionen willst du hier noch anzetteln um immer wieder als resistent gegenüber Neuem und guten Beispielen/Begründungen auf zu treten?

2. In wie fern "undefinierte Sachen"? Was ist undefiniert?

------- in common ----------

Ich bin gerne bereit es zu erläutern und auch mit Fallbeispielen näher zu bringen wo die Vorteile liegen, aber es macht einfach kein Sinn, so lange du nicht den Argumentationen versuchst zu folgen. In den ganzen Threads zuvor habe ich auch schon geschrieben, dass abstrakte Methode/Klassen nicht immer und überall Sinn machen. Es behauptet keiner du sollst nur noch abstrakte Klassen schreiben. Genauso wenig ist gesagt, das jedes Projekt, egal wie gross, mindestens eine abstrakte Klasse braucht. Ich habe auch nur ab und zu in meinen Projekten mal eine abstakte Implementation - dann aber weil sie dort an der Stelle Sinn macht und Vorteile bringt.

Es macht aber wirklich keinen Spass zu solchen Diskussionen mit dem Thema noch konstruktive Beiträge zu schreiben, so lange du daran beteiligt bist. Es ist wirklich deprimierend sich mit einer Wand zu unterhalten - da lass ich dass denn lieber. Aber anscheinend willst du es auch so, weil bisher auch jede Diskussion darauf hinaus lief, dass alle anderen aufgegeben hatten und dich bei deiner Meinung belassen hatten - mit gutem Grund wie mir scheint.

[Daniel]

Hansa, Dein Problem ist, dass Du versuchst, viele Dinge zu generalisieren - dies zieht sich durch praktisch alle größeren Diskussionen mit Dir durch und wird auch zu einem echten Problem.


Welches Beispiel zur Verwendung von abstrakten Klassen hast Du jetzt nicht verstanden?

Das: http://www.delphipraxis.net/internal...=592410#592410
oder das http://www.delphipraxis.net/internal...=592328#592328
oder das http://www.delphipraxis.net/internal...=592215#592215


Im Übrigen ist Deine Einleitung einfach nur frech und unverschämt ("... und ein Geist wirds wohl nie lernen."). Ich weiß nicht, welche Laus Dir gestern Abend über die Leber gelaufen ist, das Verhalten solltest Du dringend ändern.
:|

[Neutral General]

Ehm der Streit-Thread über Abstrakte Klassen ist woanders. Hier in meinem Thread gibts keinen Streit -.-^^ Bitte :stupid:

Also xaromz deine Idee ist nicht schlecht. Ich glaube ich werde das mal probieren :)
Und danke an alle Leute die schon das 65. mal versuchen das Thema allen zu erklären :mrgreen:

Gruß
Neutral General