#26 04.07.2012 18:04:44

DerPeer
GodlikeMember
Ort: Berlin
Registriert: 04.02.2005
Beiträge: 1291

Re: Objekt-orientierte Programmierung

Komisch. Jetzt gehts genauso, wie es sollte. Keine Ahnung, was ich alles geändert hatte. Merkwürdig...

Offline

 

#27 04.07.2012 18:13:48

DerPeer
GodlikeMember
Ort: Berlin
Registriert: 04.02.2005
Beiträge: 1291

Re: Objekt-orientierte Programmierung

Und noch einer:

Ich habe ein Objekt, das viele Procedures enthält. Einige dieser Procedures will ich in einer anderen Unit implementieren, als da, wo die Deklaration ist. Das scheint aber irgendwie nicht zu gehen:

Beispiel: 1. Unit:

Code: Delphi

unit Unit1;

interface
...
type
  Tbla = class
    procedure tuwas;
  end;

implementation

uses Unit2;
...


2. unit:

Code: Delphi

unit Unit2;

interface

uses unit1;

implementation

procedure Tbla.tuwas;
begin
  //xyz
end;


Fehler tritt in der Unit2 auf, er regt sich über den Punkt in "procedure Tbla.tuwas" auf.

Idee?

DerPeer

Offline

 

#28 04.07.2012 18:16:51

Gnietschow
ProMember
Ort: Berlin
Registriert: 20.06.2007
Beiträge: 237

Re: Objekt-orientierte Programmierung

Soweit ich weiß geht das nicht. Du musst alle Methoden auch in der Unit implementieren, wo du sie deklarierst. Du könntest nur eine abstrakte Klasse (oder nen Interface) machen, diese in der anderen Unit ableiten und dort alles implementieren und überschreiben.

MfGnietschow


Es gibt 10 Gruppen von Menschen - die die das Binärsystem verstehen und die anderen.  :-)
Vegetarier essen meinem Essen das Essen weg ;)
-------------------------------------------------------------------------------------------------------------------
Der Community-Hub für Videospiele: gameloop.io

Offline

 

#29 04.07.2012 18:30:27

DerPeer
GodlikeMember
Ort: Berlin
Registriert: 04.02.2005
Beiträge: 1291

Re: Objekt-orientierte Programmierung

Hm. Danke. Das ist sehr schlecht. Der Codeumfang ist mir nämlich zu groß, um es in eine Unit zu packen.

Vielen Dank!

DerPeer

Offline

 

#30 04.07.2012 19:02:50

DragonFlyOfGold
ProMember
Ort: Berlin
Registriert: 09.11.2005
Beiträge: 139

Re: Objekt-orientierte Programmierung

Wie viel Zeilen Code soll das Ganze denn umfassen? Eine meiner größere Units umfasst 3500 Zeilen Code ... bin gespannt auf deine Zahl;)
Eine sehr ungewöhnliche Variante wäre es, die Klasse in UnitA zu deklarieren, sagen wir mit 3 Methoden (Proceduren) und diese als abstract zu makieren. In UnitB leitest du die Klasse ab, überschreibst nur Methode1 und implementierst sie. In UnitC machst du das selbe für Methode2 usw. Dann nutzt du zum Schluß die Klasse aus UnitD, welche auf alle Implementierungen und damit eine vollständige Klasse zugreifen kann.

DfoG

Offline

 

#31 04.07.2012 21:07:26

DerPeer
GodlikeMember
Ort: Berlin
Registriert: 04.02.2005
Beiträge: 1291

Re: Objekt-orientierte Programmierung

Es sind etwa 2000 Zeilen. Aber das ist mir eigentlich auch schon zuviel. Naja, muss ich mich wohl mit arrangieren.

Deine Idee, Dragon, verstehe ich zwar, finde sie doch aber arg kompliziert. Vom hässlichen Programmieren wollte ich ja grade wegkommen, und lernen, wie man es vernünftig macht :-)

Aber ihr habt schon recht: Code von einigen "großen" Projekten war genauso: Oft ewig lange Dateien. Und wenn das alle so machen...

Übrigens kann gern ein Mod diese Thread ins Delphi-Forum verschieben - hat mit DX ja nur am Rande zu tun.

Vielen Dank euch!

DerPeer

Offline

 

#32 05.07.2012 18:02:47

Lotipats
UltraMember
Registriert: 17.05.2005
Beiträge: 395

Re: Objekt-orientierte Programmierung

Große Dateien findest du nicht nur in Delphi, sondern auch anderen Programmiersprachen, vermutlich in allen, die auch größere Projekte erlauben und "normale" Programmierparadigmen umfassen. Gesehen habe ich das schon bei C, C++, Java, Groovy/Grails und Delphi (und vllt. andere, die ich vergessen habe). Wenn der Code nun einmal zusammen gehört, dann gehört er zusammen.
Schaust du dir mal "größere" OpenSource-Projekte, siehst du das dort auch. aber es reicht schon, wenn du dir den Quellcode der mitgelieferten Bibliotheken der Entwicklungsumgebung ansiehst. Ob nun die von Delphi oder stdc-lib/libc++, auch dort ist das so.

Natürlich ist es nicht zwangsweise guter Programmierstil, wenn es nur alle so machen. Und ich verstehe auch, was du meinst, mit den großen Dateien. Schaut man sie sich z.B. das erste mal, als Fremdprogrammierer, an, dann erschlägt es einen. Aber ich habe beispielsweise auch selber mehrere solcher großen Dateien in versch. Projekten erstellt (erst heute wurde wieder eins mit u.a. einer 1560 Zeilen langen Datei abgenommen). Wenn die Dinge thematisch zusammen gehören, würde eine (damit nur willkürliche) Auseinandersetzung auch nur mehr verwirren.
Man kann halt nie alles haben, das ist ja auch mit geringem Speicherverbrauch und hoher Geschwindigkeit so. wink

LOTIPATS

Offline

 

#33 06.07.2012 19:15:06

DerPeer
GodlikeMember
Ort: Berlin
Registriert: 04.02.2005
Beiträge: 1291

Re: Objekt-orientierte Programmierung

Naja, es wird schon gehen, danke. Aber es wäre schon nicht schlecht gewesen, wenn man es wenigstens könnte - wenn man wollte. Nach der Vererbung stehen die Methoden und Properties immerhin auch in verschiedenen Klassen/Dateien.

DerPeer

Offline

 

#34 06.07.2012 19:33:17

DerPeer
GodlikeMember
Ort: Berlin
Registriert: 04.02.2005
Beiträge: 1291

Re: Objekt-orientierte Programmierung

Mal noch eine dumme Frage:

Eine meiner Methoden eines Objektes möchte ggf. das Objekt löschen. Sozusagen "von innen" heraus. Offenbar ist es kein Problem, den eigenen Destruktor aufzurufen, aber was mache ich mit der Referenz, mit deren Hilfe diese Methode von außen aufgerufen wurde?

Nehmen wir an, wir hätten ein Objekt Apfel, und es hat die Methode beißVonMirAb. In dieser Methode soll der Apfel gelöscht werden, wenn es der letzte Bissen war.

FreeAndNil funktioniert natürlich nicht.
Muss ich die Information, dass das Objekt gelöscht wurde, nach draußen propagieren?
Kann ich irgendwie herausfinden, ob ein Pointer noch tatsächlich auf ein intaktes Objekt zeigt?

Vielen Dank für eure Hilfe!

DerPeer

Offline

 

#35 06.07.2012 20:47:59

Gnietschow
ProMember
Ort: Berlin
Registriert: 20.06.2007
Beiträge: 237

Re: Objekt-orientierte Programmierung

Das Problem hierbei ist, wenn irgendwo ein Pointer existiert der auf den Apfel zeigt, dann kannst du diesen nicht vom Apfel aus erreichen. Da wär ja das ganze Klassenkonzept kaputt, wenn der Apfel wüsste wo er überall referenziert wurde. Wenn du nun irgendwie die Klasse vernichtest, zeigen alle Pointer auf einen Speicherbereich, der vll freigegeben wurde und damit nicht mehr erreichbar ist. So kannst du auch nicht testen, ob er noch valid ist. Da wäre es besser zum Beispiel für den Apfel ein Interface (die haben nämlich Referenzzähler) zu nehmen und wenn der Apfel weg ist, dann löscht du ihn nicht, sondern hast irgendeine Variable, die sagt ob er noch da ist. Wenn nicht können die anderen Klassen ihre Referenz löschen und wenn alle Referenzen weg sind, gibt sich der Apfel selbst frei. Oder du versucht deine Struktur irgendwie anders aufzubauen, so dass nicht überall Referenzen rumliegen, sondern nur an einem Punkt.

MfGnietschow


Es gibt 10 Gruppen von Menschen - die die das Binärsystem verstehen und die anderen.  :-)
Vegetarier essen meinem Essen das Essen weg ;)
-------------------------------------------------------------------------------------------------------------------
Der Community-Hub für Videospiele: gameloop.io

Offline

 

#36 12.07.2012 11:12:08

DerPeer
GodlikeMember
Ort: Berlin
Registriert: 04.02.2005
Beiträge: 1291

Re: Objekt-orientierte Programmierung

Ich bin auf eine Merkwürdigkeit gestoßen: "free" führt nicht meinen implementierten Destruktor "destroy" aus. Ist das normal? Hab ich was falsch gemacht?

Code: delphi

tbla = class
  destructor destroy;
end;
...
destructor tbla.destroy;
begin
  form1.memo1.lines.add('flag');
end;
...
var a: tbla;
begin
a:=tbla.create;
a.free;


Es erscheint keine Meldung im Memo1-Fenster.
Ersetze ich "a.free" durch "a.destroy", erscheint die Meldung.
Ich dachte, free sei dasselbe wie destroy, checkt nur vorher noch, ob die Referenz nicht nil ist.

Versteht das jemand?

Vielen Dank!

DerPeer

Offline

 

#37 12.07.2012 11:18:21

DerPeer
GodlikeMember
Ort: Berlin
Registriert: 04.02.2005
Beiträge: 1291

Re: Objekt-orientierte Programmierung

Ach herrje! Hab den Fehler gefunden: "destroy" ist eine virtuelle Methode und muss daher immer mit "override" deklariert werden.
Na jetzt weiß ich´s ;-)

DerPeer

Offline

 

#38 13.08.2012 14:08:08

DerPeer
GodlikeMember
Ort: Berlin
Registriert: 04.02.2005
Beiträge: 1291

Re: Objekt-orientierte Programmierung

Inwiefern ist es eigentich zulässig, dass ein Objekt seinen eigenen Destruktor aufruft? Theoretisch ist das Objekt nach Beendigung des Destruktors nicht mehr existent, die den Destruktor aufrufende Prozedur/Funktion ist aber noch Teil dieses Objektes und wird unter Umständen weiter ausgeführt. Ist das irgendwo dokumentiert?

Code: delphi

tklasse = class
  procedure progress;
end;

...

procedure tklasse.progress;
begin
  if irgendeinebedingung then destroy;
  // weitere Anweisungen erlaubt/verboten/nicht empfohlen?
end;


Vielen Dank!

DerPeer

Offline

 

#39 13.08.2012 14:17:31

DerPeer
GodlikeMember
Ort: Berlin
Registriert: 04.02.2005
Beiträge: 1291

Re: Objekt-orientierte Programmierung

Noch eine Frage: Ich habe eine Klasse A, die erbt direkt von TObject. MUSS ich in A´s Destruktor am Ende inherited aufrufen oder ist das in diesem Fall egal?

Danke

DerPeer

Offline

 

#40 13.08.2012 18:32:06

Carsten
ProMember
Ort: Braunschweig
Registriert: 05.01.2006
Beiträge: 220
Web-Seite

Re: Objekt-orientierte Programmierung

Man sollte inherited immer aufrufen, auch wenn es hier evtl. egal ist.
Zur Frage davor: Das Objekt muß ja irgendwie in einer übergeordneten Klasse verwaltet werden. Wenn sich das Objekt selbst zerstört (wenn das denn überhaupt so geht), dann bekommt die Klasse davon ja erstmal nichts mit und hat eine ungültige Adresse in ihrer Verwaltung -> Zugriffverletzung oder andere Effekte bei nächsten Zugriff.

Carsten

Offline

 

#41 14.08.2012 06:08:45

Lotipats
UltraMember
Registriert: 17.05.2005
Beiträge: 395

Re: Objekt-orientierte Programmierung

Zum eigenen Destruktor:
Ich schließe mich Carsten an, möchte aber eine kleine Ergänzung (mit längerem Text) machen.
Meines Wissens nach sind Destruktoren und Konstruktoren ein notwendiges, technisches Übel und nicht Teil des OOP-Konzeptes (korrigiert mich, wenn ich falsch liege). Wenn eine Instanz angelegt wird, so soll sie einen gültigen, definierten Zustand haben und beim zerstören soll aller Speicher freigegeben werden. Je nach Programmiersprache gibt es unterschiedliche Umsetzungen. In C++ wird der Destruktor z.B. von der Speicherfreigebenden-Funktion aufgerufen und jede Klasse kann seine eigene Funktion erhalten. Wenn die von dir angesprochene Funktion also Teil der Speicherverwaltung ist, dann ist es erlaubt, den eigenen Destruktor aufzurufen, ansonsten nicht, da das von Carsten beschriebene Problem entsteht.

zum inherited:
Auch hier stimme ich Carsten zu. Ein Speicherleck aufgrund eines vergessenen inherited ist schwer zu finden. Der Destruktor (wie auch der Construktor) von TObject in Delphi 2009 ist leer, 0 Zeilen effektiven Codes. Damit MUSS er nicht aufgerufen werden. Aber weißt du, was die Zukunft bringt? Vllt. bauen sie irgendwelche Features ein, so dass der Destruktor von TObject Inhalt hat. Willst du dann beim Portieren alle deine Klassen ändern? Und falls du etwas übersiehst, hast du ein Problem. wink
Deshalb einfach immer inherited nutzen, kostet ja nichts/nicht viel.

LOTIPATS

Offline

 

#42 17.08.2012 08:44:45

DerPeer
GodlikeMember
Ort: Berlin
Registriert: 04.02.2005
Beiträge: 1291

Re: Objekt-orientierte Programmierung

@Carsten: Naja, das Objekt könnte ja auch in der übergeordneten, verwaltenden Klasse seine nahende Zerstörung bekanntgeben (woraufhin diese ihre Referenz löscht). Daraufhin zerstört sich das Objekt selbst.
Und selbst wenn der Destruktor von der Verwaltungsklasse aufgerufen würde (angestoßen im zu löschenden Objekt), hätten wir dasselbe Problem.

Ja, das inherited werde ich dann mal immer benutzen.

DerPeer

Offline

 

Brett Fußzeile

Powered by PunBB
© Copyright 2002–2005 Rickard Andersson