Klasse an Klasse gleichen Typs übergeben

[Lenth]

Hallo,

ich versuche mich mal möglichst kurz auszudrücken:

Delphi-Quellcode:

tMatrixClass = Class (tObject)
               Private
                 Matrix_da_e     : TDA_e; //Soll gekapselt werden
               {Schnipp}
               Public
                 Constructor CreateByCrossProduct(Var AMatrixClass : tMatrixClass; Var BMatrixClass : tMatrixClass); 
               {Schnipp}
End;

Hier werden zum Erzeugen einer Matrix, die in einem Objekt gekapselt ist, dem Konstruktor zwei Matrizen übergeben. Interessant dabei ist, dass die übergebenen Matrizen den gleichen Typ haben, wie das Objekt selber. Dass dies geht, habe ich schon ausprobiert. Ein solches Konstukt würde gewisse Probeme bei komplexeren Matrixoperationen vermeiden helfen.

Ich wollte Fragen, ob so etwas unter die Kategorie

"Programmiere nie mals in dieser Weise"

fällt, oder ob dies eine legitime Vorgehensweise ist.


Grüße

Christoph

[edit=Jelly]Delphi Tags gesetzt, Mfg, Jelly[/edit]

[3_of_8]

Das ist nicht sonderlich gut. Der Rest deines Stils IMHO auch nicht ganz einwandfrei.

Delphi-Quellcode:

TMatrix = class(TObject)
protected
  FDA_e: TDA_e;
{Schnipp}
public
  class function Multiply(m1, m2: TMatrix): TMatrix;
  function Multiply(m2: TMatrix): TMatrix;
{Schnipp}
end;

{Schnipp}

implementation

class function TMatrix.Multiply(m1, m2: TMatrix): TMatrix;
var I, J: Integer;
begin
//Iteriere über alle Matrizenelemente von m1 und m2 mit I und J als Indizes und multipliziere
//kreuzweise, speichere Ergebnis in Result
end;


function TMatrix.Multiply(m2: TMatrix): TMatrix;
var I, J: Integer;
begin
//Iteriere über alle Matrizenelemente von self und m2 mit I und J als Indizes und multipliziere
//kreuzweise, speichere Ergebnis in Result
end;

So würde ich das machen.

Sieh dir mal die Delphi Code-Konventionen an.

Achja, das ist übrigens nur meine Meinung, die ist selbstverständlich NICHT repräsentativ.

[Der_Unwissende]

Hi,
gegen eine Verwendung von Variablen des Klassentyps in einer Klasse spricht überhaupt nichts. Insbesondere Methoden wie Assign würden ohne recht dumm nachgebaut werden müssen (gleiches gilt für z.B. Clone oder ähnliches!).
In deinem Fall würde ich dir trotzdem ein wenig davon abraten. Du gehst damit stark in die unsaubere Vermischung von verschiedenen Dingen. Das Rechnen sollte sicherlich mit verschiedenen Reealisierungen eines Vektors möglich sein. Ein Vektor ist hingegen nur ein reiner Datentyp. Hier bietet es sich also an, dass du die Logik der Vektorrechnung von seiner Repräsentation trennst. Du hast dann zwei Klassen, die nur eine bestimmte Funktionalität bieten. Der Vorteil ist, dass du hier einerseits mehr übersicht hast und andererseits sehr einfach eine der Komponenten austauschen kannst (z.B. eine effizientere Mathelogik verwenden könntest).
Zudem muss doch eigentlich ein Vektor nicht die Operationen kennen, die mit ihm gemacht werden. Das bietet den Vorteil, dass du mit beliebigen anderen Klassen diese Vektor verwenden könntest!

Gruß Der Unwissende

[Jelly]

Herzlich willkommen bei uns,

eins mal vorweg... Du hast die Möglichkeit hier Tags zu benutzen, um deinen Code besser formatiert darstellen zu können... Dafür einfach dein Delphicode so formatieren

Code:

[delphi]Dein Delphi Code[/delphi]

Ich hab das mal in deinem ersten Post einmal für dich gemacht.

Aber zu deinem Thema:
Ich würde innerhalb eines Objektes lediglich Operationen ablegen, die einzig und allein das Objekt betreffen. Matrizenmultiplikation z.B. würd ich von ausserhalb erledigen lassen, eventuell von einer getrennten Klasse TMatrixOperations o.ä.

Innerhalb von TMatrix würd ich nur so Dinge reinschreiben wie

• Invert
• Negate
• Power

also alles Dinge, die nur mit dem Objekt direkt arbeiten. Da gibts sicherlich noch mehr.

Aber ist auch nur meine Meinung. Geht bestimmt auch anders.

[3_of_8]

Ja, zum Beispiel in Java. Ich merks schon, ich bin ein bissel Java-verseucht.

Also ich denke mal, eine Klassenmethode wie von mir vorgeschlagen mag eine nette Alternative sein.

TMatrix.Multiply(m1, m2);

Eine Alternative wäre natürlich eine "normale" Funktion:

MultiplyMatrices(m1, m2);

Aber ich würde keine Konstruktoren dafür "missbrauchen".

[Lenth]

Hallo,

danke nochmal für die Tips.

Ich denke, ich werde mal aus der einen Klasse gemäß dem, was ich hier zu hören bekommen habe, zwei machen, um das ganze übersichtlicher zu gestalten.

Grüße

Christoph

[3_of_8]

Wieso zwei? Hab ich da was übersehen?

Die erste Klasse soll die Matrix sein, und die zweite?

[Der_Unwissende]

Zitat von 3_of_8:

Wieso zwei? Hab ich da was übersehen?

Zitat von Jelly:

Ich würde innerhalb eines Objektes lediglich Operationen ablegen, die einzig und allein das Objekt betreffen. Matrizenmultiplikation z.B. würd ich von ausserhalb erledigen lassen, eventuell von einer getrennten Klasse TMatrixOperations o.ä.

Zitat von Der_Unwissende:

Das Rechnen sollte sicherlich mit verschiedenen Reealisierungen eines Vektors möglich sein. Ein Vektor ist hingegen nur ein reiner Datentyp. Hier bietet es sich also an, dass du die Logik der Vektorrechnung von seiner Repräsentation trennst. Du hast dann zwei Klassen, die nur eine bestimmte Funktionalität bieten.

Nur alle anderen Beiträge?!

[3_of_8]

Ups...

Hab ich wohl überlesen.

Aber sowas wie TMatrixOperations finde ich auch nicht sonderlich toll...

Wie gesagt, ich bin für Klassenmethoden in TMatrix.

(TMatrixClass ist übrigens kein richtiger bezeichner, denn dass es eine Klasse ist, ist klar, eine TMatrixClass wäre eine class of TMatrix)

[shmia]

Dein Konstruktor bringt so für das Design nicht so viel (Alternativen wurden ja genannt).
Aber als Copy-Konstruktor wäre die Sache schon interessant:

Delphi-Quellcode:

tMatrix = Class (tObject) 
   Public 
   Constructor Create; overload; // Null Matrix
   constructor Create(x,y:Integer); overload; // leere Matrix definierter Grösse
   Constructor Create(sourcematrix : tMatrix); overload;  // Copy-Konstruktor