Einige Methoden in mehreren Klassen verwenden?

[Pseudemys Nelsoni]

Moin,

wie kann ich mehrere Methoden in mehreren Klassen verwenden ohne das ich sie für jede neu schreiben muss?

Ich habe mir überlegt das ich ja die ganzen Methoden in einer eigenen Klasse haben könnte.... aber dann müsste ich ja jede Klasse die die Methoden braucht von dieser ableiten.... ich muss aber schon von TCLientSocket ableiten...und von 2 Klassen kann ich ja nicht ableiten, also wie könnte ich das machen? ein Feld der Methoden-Klasse in der Klasse möchte ich nicht, da ich die Methoden direkt so:

Instanz1.Methode1 aufrufen können möchte


jemand ne idee?

[dizzy]

Schon mal was von Vererbung gehört? :P

Ne im Ernst: Mach eine Oberklasse die all die Funktionen implemetiert die mehrfach vorkommen, und leite davon ab. Das ist einer der Hauptgründe dafür, dass man OOP überhaupt erst entwickelt hat ;).

[Waldteufel]

Hi.

Zitat:

Zitat von dizzy

Schon mal was von Vererbung gehört? :P

Ne im Ernst: Mach eine Oberklasse die all die Funktionen implemetiert die mehrfach vorkommen, und leite davon ab. Das ist einer der Hauptgründe dafür, dass man OOP überhaupt erst entwickelt hat ;).

@dizzy: Er hat doch gesagt, dass er schon von TClientSocket ableitet... :roll:

@Pseudemys Nelsoni: Das was du beschreibst, geht meines Wissens nur in C und C++ mit der Mehrfachvererbung. Pascal unterstützt nur Interfaces, die nur beschreiben, welche Funktionen/Prozeduren vorhanden sein müssen, diese aber nicht implementieren. Pech... ;-)

[SirThornberry]

du könntest diese spezelle funktion als normale funktion anlegen und rufst dann in den Klassenfunktionen einfach die normale funktion auf

Delphi-Quellcode:

type
  TYourClass1 = class(irgendwas)
  private
    procedure dorigendwas;
  [...]
  TYourClass1 = class(irgendwas)
  private
    procedure dorigendwas;
  [...]
procedure doirgendwasproc;
begin
  showmessage('trallala');
end;

procedure TYourClass1.doirgendwas;
begin
  doirgendwasproc;
end;

procedure TYourClass2.doirgendwas;
begin
  doirgendwasproc;
end;

[Khabarakh]

Stehe ich gerade auf dem Schlauch oder spricht etwas gegen

Delphi-Quellcode:

type
  TMainClass = class(TClientSocket)
  [...]

  TClass1 = class(TMainClass)

...

?

[dizzy]

Zitat:

Zitat von Khabarakh

Stehe ich gerade auf dem Schlauch oder spricht etwas gegen

Delphi-Quellcode:

type
  TMainClass = class(TClientSocket)
  [...]

  TClass1 = class(TMainClass)

...

?

Wovon rede ich denn die ganze Zeit? :P

[Khabarakh]

Zitat:

Zitat von dizzy

Zitat:

Zitat von Khabarakh

Stehe ich gerade auf dem Schlauch oder spricht etwas gegen

Delphi-Quellcode:

type
  TMainClass = class(TClientSocket)
  [...]

  TClass1 = class(TMainClass)

...

?

Wovon rede ich denn die ganze Zeit? :P

Genau davon. Nur will niemand die Lösung wahrhaben :freak: .

[Waldteufel]

Hi.

Zitat:

Zitat von Khabarakh

Zitat:

Zitat von dizzy

Zitat:

Zitat von Khabarakh

Stehe ich gerade auf dem Schlauch oder spricht etwas gegen

Delphi-Quellcode:

type
  TMainClass = class(TClientSocket)
  [...]

  TClass1 = class(TMainClass)

...

?

Wovon rede ich denn die ganze Zeit? :P

Genau davon. Nur will niemand die Lösung wahrhaben :freak: .

@Khabarakh: Ja. Du stehst auf dem Schlauch... Geh mal bitte runter, ich muss nämlich noch die Blumen gießen... ;-)

Er will eine Klasse TMeineLieblingsmethoden erstellen und seine Klasse davon ableiten. Dummerweise MUSS seine Klasse aber auch von TClientSocket abgeleitet sein. Das lässt sich nur über Mehrfachvererbung lösen, die es aber in Delphi/Pascal/ObjectPascal nicht gibt. (<- Punkt!)

[dizzy]

One word: Nope

Delphi-Quellcode:

type
  TMyMethodsAreHere = class(TClientSocket)
  private
    ...
  public
    procedure IchTuWas;
    function IchGebWas: Integer;
  end;

  TMyClass1 = class(TMyMethodsAreHere)
    .
    .
  end;

  TMyClass2 = class(TMyMethodsAreHere)
    .
    .
  end;

var
  x: TMyClass1;
  y: TMyClass2;

begin
  x := TMyClass1.Create(...);
  y := TMyClass2.Create(...);

  x.IchTuWas;
  y.IchGebWas;
end.

Packs in den Compiler und sieh selbst!

[Waldteufel]

Hi.

14 Words : Er will doch, dass er seine Klasse TMeineMethoden unabhängig von diese, speziellen Fall hat.

C++-Beispiel:

Code:

class MyMethods {
  private:
  protected:
  public:
    MyMethods() {};
    ~MyMethods() {};
   MachDies() { /* tätäää */ }
   MachDas() { /* tataaa */ }
};

class MeinSocket : public MyMethods, public TServerSocket {
  /* ... */
};

/* aber auch : */

class MeineTextverarbeitung : public MyMethods, public TTextInput {
  /* ... */  
};

Da Pascal/ObjectPascal/Delphi aber keine Mehrfachvererbung hat geht das nicht!

[Robert_G]

Einen Hauch von MultiInheritance gibt's mit den class helpers in D2005.

Eklig wird's wenn er ab 2 Punkten in 2 getrennten Ästen in seiner Hierarchie diese Funktionen haben will.

Da ich kaum glaube, dass dizzy die Lösung geliefert hat* wäre es mal ganz gut seine Meinung zu hören...

*nix gegen dich, ich denke nur einfach Pseudo ist nicht so ein Noob ;)

[Sanchez]

Zitat:

Zitat von Waldteufel

Da Pascal/ObjectPascal/Delphi aber keine Mehrfachvererbung hat geht das nicht!

Und das ist auch gut so.

So wie ich das Ganze sehe, steht der Waldteufel aufm Schlauch.

Der Unterschied zwischen:

Delphi-Quellcode:

type 
  TMainClass = class(TClientSocket) 
  [...] 

  TClass1 = class(TMainClass) 

...

und

Delphi-Quellcode:

type 
  TMainClass = class(TClientSocket, TKlasseMitDenMethoden) 
  [...] 

...

ist doch quasi nicht vorhanden. Und wenn man diese Methoden nicht überall benötigt, schiebt man halt noch eine Klasse dazwischen.

[Waldteufel]

Hi.

Pseudemys Nelsoni will eine von seinem Beispiel unabhängige Klasse. Sowas wie ein Interface, nur mit bereits implementierten Methoden. ;-)

@Sanchez: Wenn ich dich richtig verstehe, ist bei dir TMainClass die Klasse mit den Methoden. Ja? Gut. Was ist, wenn ich TMainClass noch wo anders brauche, wo ich aber von TComboBox ableiten muss? ;-)

[bttb930]

Ach Leute,

wieso hört ihr einander nicht zu? Die Lösung steht oben schon mehrfach, lest einfach mal und DENKT mit.

[Sanchez]

Zitat:

Zitat von Waldteufel

Was ist, wenn ich TMainClass noch wo anders brauche, wo ich aber von TComboBox ableiten muss? ;-)

:warn: Das hat Pseudo nicht gefragt. Warum sollte ich mir über Dinge den Kopf zerbrechen, um die es überhaupt nicht geht?

[Sanchez]

Zitat:

Zitat von Waldteufel

Was ist, wenn ich TMainClass noch wo anders brauche, wo ich aber von TComboBox ableiten muss? ;-)

BTW: Würde ich in einem solchen Fall an einen gemeinsamen Vorfahren delegieren. Du hasts geschafft, dass ich mir doch den Kopf darüber zerbrochen habe :)

Also:

Delphi-Quellcode:

type TKlasseMitMethoden = class
  protected
    FObjekt: TVorfahrVonDenGewünschtenKlassen;
    procedure MachWasMitFObjekt;
...
  end;

  TKlasseMitComboBox = class(TKlasseMitMethoden)
  public
    constructor Create(_owner : TComponent);
...
  end;

  TKlasseMitIrgendeinemAnderenObjekt = class(TKlasseMitMethoden)
  public
    constructor Create(_owner : TComponent);
...
  end;
...

TKlasseMitComboBox.Create(_owner : TComponent);
begin
  FObjekt := TComboBox.Create(_owner);
end;

TKlasseMitComboBox.Create(_owner : TComponent);
begin
  FObjekt := TIrgendeinAnderesObjekt.Create(_owner);
end;

[Pseudemys Nelsoni]

Moin,

ui da sind aber viele Posts :shock: .

Zitat:

Schon mal was von Vererbung gehört? :P

Gegenfrage: Hast du meinen Post richtig durchgelesen? (Ist nich böse gemeint, falls es sich so anhört)

Zitat:

@dizzy: Er hat doch gesagt, dass er schon von TClientSocket ableitet... :roll:

Genau :thumb:

Zitat:

@Pseudemys Nelsoni: Das was du beschreibst, geht meines Wissens nur in C und C++ mit der Mehrfachvererbung. Pascal unterstützt nur Interfaces, die nur beschreiben, welche Funktionen/Prozeduren vorhanden sein müssen, diese aber nicht implementieren. Pech... ;)

Das hört sich ganz und gar nicht gut an :(

Zitat:

du könntest diese spezelle funktion als normale funktion anlegen und rufst dann in den Klassenfunktionen einfach die normale funktion auf

Wenn es keine andere Lösung gibt, dann werd ich das wohl machen (müssen).

Zitat:

Stehe ich gerade auf dem Schlauch oder spricht etwas gegen
Quellcode: markieren
type
TMainClass = class(TClientSocket)
[...]

TClass1 = class(TMainClass)

...

?

Ja tust du. In deinem Beispiel hätte TMainClass wie auch TClass1 nämlich von TClientSocket geerbt. Bloss brauch ich das in letzterer Klasse kaum.

Zitat:

Wovon rede ich denn die ganze Zeit? :P

Das frage ich mich auch die ganze Zeit. Ich glaube ihr zwei versteht mich nicht *g*

Zitat:

Genau davon. Nur will niemand die Lösung wahrhaben

Oder niemand kann was mit ner falschen Lösung anfangen :)

Zitat:

Er will eine Klasse TMeineLieblingsmethoden erstellen und seine Klasse davon ableiten. Dummerweise MUSS seine Klasse aber auch von TClientSocket abgeleitet sein. Das lässt sich nur über Mehrfachvererbung lösen, die es aber in Delphi/Pascal/ObjectPascal nicht gibt. (<- Punkt!)

Genau darum gehts :thumb:

Zitat:

Packs in den Compiler und sieh selbst!

Bei deinen Beispielen erben TMyClass1 und TMyClass2 aber AUCH von TClientSocket! Das ist total unnütz da ich in den anderen Klassen keinen ClientSocket brauche.

Zitat:

Da Pascal/ObjectPascal/Delphi aber keine Mehrfachvererbung hat geht das nicht!

Das ist ja dumm :cry:

Zitat:

Eklig wird's wenn er ab 2 Punkten in 2 getrennten Ästen in seiner Hierarchie diese Funktionen haben will.

Ich denke das was du da beschrieben hast ist das was ich vorhabe(hatte) ;) Aber ich schreib nach den Quotes nochmal genau was ich meine, zumindest werde ich das versuchen

Zitat:

*nix gegen dich, ich denke nur einfach Pseudo ist nicht so ein Noob ;)

:angel: :oops: :love:

Zitat:

wieso hört ihr einander nicht zu? Die Lösung steht oben schon mehrfach, lest einfach mal und DENKT mit.

Weil es nicht das ist was ich wollte.




Also nochmal: Gehen wir mal davon aus das ich eine Methoen-Klasse erstellt habe die ich in unterschiedlichen Klassen "einbinden" will.
Meinet wegen sieht sie so aus:

Delphi-Quellcode:

TMethodClass = class(TObject)
private
  function func1: Integer;
  function func2: Integer;
  function func3: Integer;
end;

So, der implementations-Teil ist natürlich auch geschrieben, aber den muss ich hier ja nicht mit schreiben ;)

Nun habe ich meine Hauptklasse, sie ist von TClientSocket abgeleitet. So, da das nun so ist, wie kann ich da gleichzeitig von TMethodClass erben?

Wie ich bereits gelesen hab geht das nicht, das ist natürlich doof. Vielleicht hat ja noch jemand ne Idee, sonst übernehm ich wohl das von SirThornberry. Auch wenn mir das nichtmehr nach OOP aussieht :(

Danke an alle schonmal für die Antworten ;)

[Sanchez]

@Pseudo: Hast du meinen letzten Beitrag gelesen? Ich schätze, diese Methode ist bei dir Anwendbar.

[Pseudemys Nelsoni]

Moin Sanchez,

jo habe ich ;)

aber:

Zitat:

ein Feld der Methoden-Klasse in der Klasse möchte ich nicht, da ich die Methoden direkt so:

Instanz1.Methode1 aufrufen können möchte

:|

[SirThornberry]

@Pseudo: Wenn du das so wie in meinem Beispiel machst musst du ja auch nich unbedingt eine "globale" funktion aufrufen sondern könntest auch eine Klassenmethode aufrufen (also eine methode vor der class steht)

[dizzy]

Ich muss um Verzeihung bitten, wenn meine Postings bisher etwas ...naja klangen. Das war eher locker flockig gemeint :). Ich denke ich habe das Problem an sich durchaus verstanden. Aber ich glaube ich weiss was mit zu obigem Schluss getrieben hat:

Zitat:

Zitat von Pseudemys Nelsoni

dann müsste ich ja jede Klasse die die Methoden braucht von dieser ableiten.... ich muss aber schon von TCLientSocket ableiten...

Anhand dieses Beispiels nahm ich an, dass du unterschiedliche Klassen erstellt, die alle und auch nur von TClientSocket erben, und nichts anderem. Sehe ich das richtig, dass TClientSocket nur ein Beispiel war? Wenn nicht, dann blicke ich noch immer wohl nicht voll durch.

Zitat:

Zitat von Pseudemys Nelsoni

In deinem Beispiel hätte TMainClass wie auch TClass1 nämlich von TClientSocket geerbt. Bloss brauch ich das in letzterer Klasse kaum.

Du musst von TClientSocket ableiten, brauchst das aber in einer tieferen Ableitung nicht mehr? Warum musst du dann erst überhaupt von TClientSocket ableiten? :gruebel:

Aber ich glaube etwas was man "generischen Vorfahrentyp" nennen könnte, wäre was du suchst oder? (Ist mir noch nie unter gekommen :))

[Pseudemys Nelsoni]

@ST: Ich versuchs mal, danke ;)

@dizzy

Zitat:

Du musst von TClientSocket ableiten, brauchst das aber in einer tieferen Ableitung nicht mehr? Warum musst du dann erst überhaupt von TClientSocket ableiten?

Vielleicht habe ich mich auch ein ewnig unverständlich ausgedrückt, wenn dem so ist, dann sorry ;)

Es ist nicht so das ich in einer tieferen ableitung keinen ClientSocket mehr brauche, denn ich leite nicht noch einmal von einer Klasse ab. Es geht darum das ich eine Klasse in 2 _verschiedenen_ Klassen benutzen kann.

Um nochmal mein Beispiel zu nennen:

Delphi-Quellcode:

TMethodClass = class(TObject) 
private 
  function func1: Integer; 
  function func2: Integer; 
  function func3: Integer; 
end;

Das wäre meine Methoden-Klasse die ich innerhalb einer Klasse brauche die bereits schon von TClientSocket ableitet:

Delphi-Quellcode:

TAnotherClass = class(TClientSocket)
end;

^^^^ in diese Klasse möchte ich nun aber auch noch von TMethodClass ableiten damit ich dessen Methoden benutzen kann.

So etwas wie:

Delphi-Quellcode:

TAnotherClass = class(TClientSocket, TMethodClass)
end;

Aber das geht wohl nicht...


Danke für deine Hilfe trotzdem ;)

[Fossibaer58809]

Hallo zusammen,

eventuell ergibt sich eine Lösung im Zusammenhang mit den oben erwähnten Interfaces, eben durch "Delegieren an eine Eigenschaft vom Typ einer Klasse" (siehe OH, mit Beispiel).

Gruß
Michael

[Hansa]

Zitat:

Zitat von Pseudemys Nelsoni

...Aber das geht wohl nicht...

So nicht. 8)

[Robert_G]

Ich wollte dir gerade einen kleinen Bleisitift basteln. Doch mein D7 fand es irgendwie cooler abzurauchen. :wall:

Ich habe dir noch ein klitzekleines Beispiel gefriemelt. Aus obengenanntem Abkacker ist mir die
Lust am Kommentieren vergangen. Die Bezeichner dürften aber, zusammen mit der minimalen Funktionalität ( :mrgreen: ), selbstklärend sein.

Im Endeffekt leiten alle Klassen von einem Vorfahren ab.
Spätere Ableitungen implementieren ein Interface durch das sie generisch behandelt werden können.

[Fossibaer58809]

Auch ich habe eben auf Grund meines Postings eine kleine Demoapp gebastelt.
Sie hängt hier dran.

Gruß
Michael

[dizzy]

Ich denke ich komme der Sache näher :D

Hatte gerad auch noch eine kleine Idee dazu, die aber (in meiner Version) voraussetzt, dass Parameterliste und evtl. Rückgabetyp der einzuerbenden Methoden alle gleich sind. Vielleicht lässt sich das ja auch noch umbasteln... Ist grad zu spät um da noch qualifiziert weiter zu denken :)

Hier mal was mir grad in den Sinn kam:

Delphi-Quellcode:

type
  TCFunc = function(a, b: Integer): Integer of object;

  TMethodClass = class
  public
    class function Add(a, b: Integer): Integer;
    class function Sub(a, b: Integer): Integer;
  end;

  TMyClass = class
  private
    FMethods: TMethodClass;
    function GetMethod(s: String): TCFunc;
  public
    property Method[s: String]: TCFunc read GetMethod; default;
  end;

implementation

{ TMethodClass }

class function TMethodClass.Add(a, b: Integer): Integer;
begin
  result := a+b;
end;

class function TMethodClass.Sub(a, b: Integer): Integer;
begin
  result := a-b;
end;

{ TMyClass }

function TMyClass.GetMethod(s: String): TCFunc;
begin
  if s = 'Add' then result := FMethods.Add
  else
  if s = 'Sub' then result := FMethods.Sub;
end;

// Anwendung

procedure TuWas;
var
  tmp: TMyClass;
  x: Integer;
begin
  tmp := TMyClass.Create;
  x := tmp.Method['Add'](2, 3);
  x := tmp.Method['Sub'](x, 5);
  // Leider klappt, trotz default-tag folgendes nicht:
  x := tmp['Add'](2, 3);
  x := tmp['Sub'](x, 5);
  // Der Compiler meckert, aber ich kann nicht nachvollziehen warum :\
  tmp.Free;
end;

end.

Naja, wollts nur nicht vorenthalten haben - evtl. lohnt es sich ja doch da weiter zu denken. :)


Gudde Nacht,
Fabian

[maximov]

Moin zusammen :)

Soweit ich das beurteilen kann - und das kann ich (AUS! Robert) - ist die lösung von Fossibaer58809 die, die der ausgangsfragestellung am nächsten kommt, wenn sie sie nicht sogar komplett erfüllt. Das gefrimel von robert und dizzy ist zwar cool, aber echt nicht so elegant wie diese delphi-'delegates'. *und.hopp.und.weg*

:thumb: Weiter so! Ich liebe solche threads, wo über elementares geredet wird und nicht über klickie-gelöt :mrgreen:

[Robert_G]

Jo, interface implementierende properties sind schon irgendwo cool. :)

In meinem Bleistift sollte die Property (Name) aber nur vom Besitzer der versteckten Instanz gehandhabt werden.
Es sollte ja kein Umdenken nötig werden um in späteren Ableitungen damit umzugehen. (Deshalb ja auch ein fixer RefCount von 1 ;) )
Genau da verlässt man IMHO die Möglichkeiten einer implementierenden property. :?

Wie gesagt, die Idee ist sau cool. Die Technik dahinter auch.
Ich denke dass wäre eine verflucht elegante Lösung gegen das leidige Problem der Typisierung/Generalisierung bei eigenen Collections. :)
Also wie es in .Net mit der expliziten Implementierung erfolgt. ;)

Code:

  void IList.Add(object value)
  {
     Add(MyItemType(value));
  }

  public void Add(MyItemType value)
  {
     ...
  }

Danke nochmal, gefällt mir immer mehr... :thuimb:

[maximov]

Zitat:

Zitat von Robert_G

...
Wie gesagt, die Idee ist sau cool. Die Technik dahinter auch.
Ich denke dass wäre eine verflucht elegante Lösung gegen das leidige Problem der Typisierung/Generalisierung bei eigenen Collections. :)
Also wie es in .Net mit der expliziten Implementierung erfolgt. ;)

Code:

  void IList.Add(object value)
  {
     Add(MyItemType(value));
  }

  public void Add(MyItemType value)
  {
     ...
  }

Danke nochmal, gefällt mir immer mehr... :thuimb:

Welche idee? und welche technik? Hab grad den kontext verloren, bzw. weiss jetzt nicht auf wen du das beziehst.

[dizzy]

Zitat:

Zitat von maximov

die lösung von Fossibaer58809 [ist] die, die der ausgangsfragestellung am nächsten kommt

Hab mir das jetzt mal angesehen, und muss sagen: :thumb:
Interface implementierende Properties hab ich noch nie zuvor gesehen, und's is sau-cool :D

Zitat:

Zitat von maximov

Das gefrimel von robert und dizzy ist zwar cool, aber echt nicht so elegant

Wir sind cool 8) (Wer will da noch elegant sein?)

Zitat:

Zitat von maximov

Weiter so!

Is doch jetzt fertig :mrgreen:

[Robert_G]

Zitat:

Zitat von maximov

Welche idee? und welche technik? Hab grad den kontext verloren, bzw. weiss jetzt nicht auf wen du das beziehst.

Ich hoffe dadurch die Größe dieser Delphi-Pseudo templates reduzieren zu können und die Colelctions zur Not auf einen kleinsten gemeinsamen Nenner zusammenfassen zu können.
Sicher könnte ich Interfaces als protected implementieren, aber mit Fossibärs Ansatz könnte ich die Größe der Templates drastisch reduzieren. ;)

Es geistert mir nur gerade so im Kopf rum... am WE schaue ich es mir nochmal genauer an...

[maximov]

@Robert: Na, da darf man dann ja gespannt sein. Seh grad: In deiner version arbeitest du ja mit iterator-interfaces. Ich vermute mal darauf beziehen sich deine ideen? Ich bin mal gespannt wie du das genau meinst. Auf jeden fall will ich der erste sein, der das zu gesicht bekommt :-D

[Robert_G]

Ich hol' den nochmal hervor...

Erstens interessiert mich natürlich wie es Pseudo realisiert hat und zweitens dürfte es zu den Standardnervigkeiten gehören.
Nicht schwer zu umschiffen, doch wirklich elegant war bisher keine Lösung...
Also... Wie handhabt ihr die Problematik? :) Nicht zimperlich sein. hier beißt keiner. ;)
Außer vielleicht dizzy.... Wer auf eine Methode über einen String zugreift frisst sicher auch kleine Kinder. :mrgreen:

[maximov]

Zitat:

Zitat von Robert_G

Ich hol' den nochmal hervor...

Erstens interessiert mich natürlich wie es Pseudo realisiert hat und zweitens dürfte es zu den Standardnervigkeiten gehören.
Nicht schwer zu umschiffen, doch wirklich elegant war bisher keine Lösung...
Also... Wie handhabt ihr die Problematik? :) Nicht zimperlich sein. hier beißt keiner. ;) ..

Wir reden ja immernoch von mehrfachvererbung und die ist in delphi einfach nicht vorgesehen. Das einzige mittel um ähnliches zu realisieren dürften da dann schnittstellen sein. Zudem haben wir mit den interface-impl-properties eine prima möglichkeit sie wieder zu verwenden, ohne sie neu implementieren zu müssen, bzw. von hand delegieren zu müssen. Also würde ich sagen, das diese lösung für Delphi am aller optimalsten ist :)