Abstract oder überhaupt nicht?

[Jelly]

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

[Neutral General]

Zitat von Der_Unwissende:

Zitat von Neutral General:

erm..*hust*

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 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 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 von Hansa:

Hier steht die Frage :

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.
Eine dementsprechende Diskussion gabs bereits mal: *klick*

greetz
Mike

[Hansa]

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. Aber wo ist jetzt die Antwort ? Es fehlt die Begründung, undefinierte Sachen zu benutzen.

[JasonDX]

Zitat von Hansa:

Echt schön. 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 von Hansa:

Echt schön. 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.