Klassen? Warum?

[Qwert Zuiopü]

Hallo,
ich hab vor längerer Zeit ein Programm mit einer Klasse gesehen. Wozu braucht man die :?:
oder wofür verwendet ihr sie :gruebel:
Gruß Qwert

[Sanchez]

Hallo,

Ich hab schon jahrelang kein Programm mehr ohne Klassen gesehen, schon gar nicht wenn man mit Delphi arbeitet und die VCL benutzt.

Sieh dir das mal an: http://de.wikipedia.org/wiki/Objekto...Programmierung

grüße,
daniel

[API]

Klassen sind dabei als Prototypen anzusehen, nach denen Objekte gebildet werden.
Ich schlage dir vor, eine Einführung zu OOP zu lesen. Siehe z.B Link oben oder Suche in Google nach OOP Delphi

[Qwert Zuiopü]

also werden sie für die Systematik in einem Programm erstellt?

[mkinzler]

Klassen sind Grundlage des objektorientierten Paradigmas.

[DeddyH]

Um es mal einfach auszudrücken: Klassen sind "Blaupausen" der instanziierten Objekte.

[Qwert Zuiopü]

könnte man nicht genauso gut ohne klassen arbeiten?

[DeddyH]

Natürlich könnte man das (wurde ja schließlich jahrzehntelang getan), aber das wäre zumindest in größeren Programmen kontraproduktiv.

[Qwert Zuiopü]

weil?

[DeddyH]

Weil sonst z.B. ein Konzept wie die VCL nur schwer zu realisieren wäre.

[alzaimar]

Zitat:

Zitat von Qwert Zuiopü

könnte man nicht genauso gut ohne klassen arbeiten?

'auch' : Ja.
'genauso gut' : Nein.

Heutzutage beauftragt man ein Logistikunternehmen, eine Produktionsstätte inklusive Knowledgetransfer, Zollformalitäten, Schulungen, Maschinen, Infrastruktur etc. nach Molwanien zu verlagern.

'Geht das nicht genausogut mit einem Fahrad inkl. Anhänger'?

'auch' : Ja.
'genauso gut' : Nein.

Edit: Komplexe Applikationen sind ohne OOP nicht mehr so einfach zu realisieren. Erst der Paradigmenwechsel zur objektorientierten Sichtweise ermöglicht es, größere Programme (etwas) fehlerfrei(er) und (ein wenig) robust(er) zu entwickeln. Es wird mit Sicherheit noch weitere Paradigmenwechsel nötig sein, um Anwendungen in status nascendi wirklich brauchbar und robust zu erzeugen.

Aber natürlich ist dein Dilemma offensichtlich: Letztendlich wird ja OOP in den guten alten Spaghetti-Code (=Assembler) übersetzt.

[Apollonius]

Die objektorientierte Programmierung führt u.A. zu besserer Wartbarkeit. In größeren Projekten sind sie daher sehr sinnvoll. Aber: Das Programmierparadigma muss dir dienlich sein, nicht umgekehrt. Ich halte nichts davon, Klassen um ihrer selbst willen zu verwenden.

[DeddyH]

Zitat:

Zitat von alzaimar

Zitat:

Zitat von Qwert Zuiopü

könnte man nicht genauso gut ohne klassen arbeiten?

'auch' : Ja.
'genauso gut' : Nein.

Heutzutage beauftragt man ein Logistikunternehmen, eine Produktionsstätte inklusive Knowledgetransfer, Zollformalitäten, Schulungen, Maschinen, Infrastruktur etc. nach Molwanien zu verlagern.

'Geht das nicht genausogut mit einem Fahrad inkl. Anhänger'?

'auch' : Ja.
'genauso gut' : Nein.

Schön ausgedrückt :thumb:

[DeddyH]

Wobei ich Appolonius auch Recht geben muss, man muss ja nicht um jede Ausgabezeile gleich eine Klasse bauen: Hello World

[Qwert Zuiopü]

also legt man z.B. in einer klasse das bild eines männchen,seine x- und y- koordinaten fest, und sagt(schreibt) dann später in einer Prozedur:

Delphi-Quellcode:

if j=10 then
 begin
 maennchen.x:=maennchen.x+1;
 end;

[SirThornberry]

agenommen du baust einen Messanger. Für jeden Gesprächspartner hat mein ein eigenes Nachrichtenfenster. Es wäre jetzt unsinn 100 solche Fenster zu bauen um im schlimmsten Fall mit 100 Leuten zu texten. Einfacher ist es da eine Fensterklasse zu stellen und einfach 100 Instanzen zu erstellwen wenn sie benötigt werden (also 100 mal Create).
Mit Objectorientierter Programmierung sieht der Quelltext hübsch und niedlich aus.

Natürlich kann man das ganze auch ohne Objekteorientierter Programmierung machen (also ohne direkt Objecte zu nutzen) aber der entstehende Quelltext ist dann wohl letztendlich der gleiche der bei Objekten im verborgenen umgesetzt wird.

[Nikolas]

Eher nicht. Man schreibt eher eine Funktion die das übernimmt, also:

Delphi-Quellcode:

if j=10 then
begin
maennchen.move(1,0)
end;

Wie du die Position intern verarbeitest, sollte man nicht mehr sehen. Sowas nennt sich 'information hiding'. Du kannst es dir so vorstellen, dass jemand eine Klasse schreibt und jemand anders nicht den ganzen Code kennt, sondern nur die Funktionen mit Beschreibungen.
Wie die Position intern gespeichert wird (als int, string, whatever), kann demjenigen, der die Klasse benutzt egal sein.

[Christian Seehase]

Moin Qwert,

ich möchte mal behaupten, dass Du wenige Delphi-Programme, ohne eine Klassen finden wirst.
Wenn es nicht gerade ein Konsolenprogramm ist, sondern mindestens ein Formular enthält, hast Du eine auf jeden Fall einmal ein Application-Objekt (eine Instanz der Klasse TApplication), und ein Formular-Objekt (eine Instanz der Klasse TForm, bzw., standardmässig, TForm1).

Die ursprüngliche Idee hinter der Objekt-Orientierten-Programmierung war es, dass die reale Welt sich eigentlich auch "nur" aus Objekten zusammensetzt.
Klassen stellen hierbei, sozusagen, den Bauplan für Objekte zur Verfügung.
Sie können Felder, Methoden, und Eigenschaften haben.
Felder sind, i.d.R., klasseninterne Variablen.
Methoden sind Prozeduren und Funktionen, mit denen die Daten verarbeitet werden können.
Eigenschaften dienen dazu Daten zwischen einem Objekt und anderen Programmteilen austauschen zu können.

Klassen können auch voneinander Erben (Klassen können voneinander abgeleitet werden).

Um mal das Eingangsbeispiel zu verwenden:
Wenn man ein neues Programm erstellt, wird hierfür, standardmässig, eine Klasse TForm1 generiert, die von TForm erbt.
Solange man nichts weiter hinzufügt, sind TForm1 und TForm identisch.
Wenn man jetzt einen Button auf das Formular legt, ist TForm1 eine eine Ableitung von TForm, die um ein Feld (Button1) ergänzt wurde.

Das war jetzt zwar erst einmal ziemlich kurz, aber ich hoffe es hat ein wenig Einblick gegeben.

Verwenden kann man Klassen dann in vielfältiger Weise.
In den meisten Programmen habe ich beispielsweise ein Klasse für die Einstellungen.
Damit kann ich die Funktionalität Einstellungen zu speichern und zu laden, so auslagern, dass es für das restliche Programm völlig uninteressant ist, wie das geschieht. Ob ich die Einstellungen in einer Datei lokal auf dem Rechner speichere, oder in der Registry spielt dann keine Rolle, und kann jederzeit geändert werden, ohne das der übrige Programmablauf davon beeinflusst wird.

Eine andere Möglichkeit ist es bestehende Klassen zu ergänzen, um sie den eigenen Bedürfnissen anzupassen.
Ein Beispiel hierfür:
TImage merkt sich niemals, woher jetzt die geladene Graphik stammt.
Also leite ich mir eine Klasse von TImage ab, in der ich mir den Pfad merke:

Delphi-Quellcode:

type
  TMyImage = class(TImage)
  private
    FsFilePath : string;
  public
    // Eine neue Methode
    procedure LoadFromFile(const AsFilepath : string);
    // Eine neue Eigenschaft
    property Filepath : string read FsFilePath;
  end;

procedure TMyImage.LoadFromFile(const AsFilepath: string);
begin
  // die in TImage enthaltene Eigenschaft Picture nutzen, um das Image zu laden
  Picture.LoadFromFile(AsFilepath);
  // und gleichzeitig den verwendeten Pfad speichern
  FsFilePath := AsFilepath;
end;

Alle übrigen Eigenschaften und Methoden von TImage bleiben hierbei erhalten.

Man könnte das jetzt noch variieren:

Delphi-Quellcode:

type
  TMyImage = class(TImage)
  private
    FsFilePath : string;
    // Die, sogenannte, Setter-Methode für eine Eigenschaft 
    // (Getter-Methoden kann man auch verwenden, ist hier allerdings nicht
    // unbedingt sinnvoll)
    procedure SetFilePath(const Value: string);
  public
    property Filepath : string read FsFilePath write SetFilePath;
  end;

procedure TMyImage.SetFilePath(const Value: string);
begin
  Picture.LoadFromFile(Value);
  FsFilePath := Value;
end;

Das Image wird einfach durch das Zuweisen eines Pfades geladen.

[mkinzler]

Zitat:

also legt man z.B. in einer klasse das bild eines männchen,seine x- und y- koordinaten fest, und sagt(schreibt) dann später in einer Prozedur:

Hierfür würde ja ein Record reichen. Die Vorteile von Klassen leigt aber woanders.

[Nikolas]

Eher nicht. Man schreibt eher eine Funktion die das übernimmt, also:

Delphi-Quellcode:

if j=10 then
begin
maennchen.move(1,0)
end;

Wie du die Position intern verarbeitest, sollte man nicht mehr sehen. Sowas nennt sich 'information hiding'. Du kannst es dir so vorstellen, dass jemand eine Klasse schreibt und jemand anders nicht den ganzen Code kennt, sondern nur die Funktionen mit Beschreibungen.
Wie die Position intern gespeichert wird (als int, string, whatever), kann demjenigen, der die Klasse benutzt egal sein.

Du hast grundsätzlich Vorteile:

a) Du kannst Code wiederbenutzen. Wie bei dem Messenger-Beispiel brauchst du nur einmal den Code schreiben und kannst ihn hundert Mal benutzen. Wenn du die Klasse in eine eigene Unit packst, kannst du die Klasse mit wenigen Zeilen in einem anderen Projekt nutzen, ohne den Code kopieren zu müssen.

b) Wenn du etwas am Code ändern willst, machst du das an einer Stelle und nicht an hundert. (Viel Spaß beim Suchen :) ). Wenn du einen Fehler machst, musst du ihn nur an einer Stelle korrigieren.

c) das eben erwähnte Information Hiding. Wenn die Klasse fertig ist, brauchst du nicht mehr so genau wissen, wie es intern funktioniert. Bestes Beispiel ist die GUI. Wohl niemand weiss so ganz genau, wie ein Button funktioniert, aber eine On-klick Methode kann jeder DAU schreiben.

[Qwert Zuiopü]

zusammenfassend: eine klasse wird hauptsächlich dann verwendet, wenn, man häufiger etwas durchführen muss z.B.(um nocheinmal auf das beispiel mit den männchen zurückzukommen), um das männchen öfter zeichnen, z.b. in 40 fällen
oder?

[DeddyH]

Vielleicht etwas besser ausgedrückt: wenn man 40 Männchen braucht ;)

[mkinzler]

Jein. das ist zwar auch ein Vorteil aber nicht Hauptvorteil. Beschäftige dich mal mit den Grundlagen der OOP:
http://de.wikipedia.org/wiki/Objekto...Programmierung

[SirThornberry]

einen der wichtigsten Punkte finde ich die Vererbung. Das Beispile mit TForm1 welches von TForm abgeleitet ist finde ich schon supi. Klar könnte man ohne Objekte auch einfach TForm hernehmen und den Quelltext erweitertn aber dann wäre er in allen Projekten geändert. Oder man kopiert den Quelltext von TForm und ändern dann darn rum.
Wenn man aber später in TForm einen Bug findet muss man überall diesen Fehler beheben weil ja eine kopie gemacht wurde welche geändert wird. Bei Vererbung ändert man einfach seine Klasse und alle die davon geerbt haben sind ebenfalls von der Fehlerbereinigung betroffen

[Qwert Zuiopü]

ich danke euch zuerst einmal für die antworten.

wahrscheinlich liegt es daran, dass ich so selten klassen gebrauche, dass ich relativ selten (eig. gar nicht) umfangreiche Programme schreibe. :wall:

Ich werde die Frage nachher als beantwortet kennzeichnen.

Gruß Qwert

[grenzgaenger]

Zitat:

Zitat von SirThornberry

Bei Vererbung ändert man einfach seine Klasse und alle die davon geerbt haben sind ebenfalls von der Fehlerbereinigung betroffen

das ist ja eigentlich der vorteil der procedurealen programmierung. nicht des OOP.

der vorteil von OPP ist einfach der, dass man den Code und die Daten vereinigen kann. somit weiss der code immer wie die daten zu interpretieren sind. somit wird die komplexität des programs geringer und damit auch die möglichen fehlerquellen. so wurde damals OPP als ein ausweg aus der Softwarekrise gesehen. In der Zwischenzeit, trat hier jedoch Ernüchterung ein, und wird nun als ein Schritt gesehen.

[Nuclear-Ping]

Zitat:

Zitat von Qwert Zuiopü

also legt man z.B. in einer klasse das bild eines männchen,seine x- und y- koordinaten fest, und sagt(schreibt) dann später in einer Prozedur:

Delphi-Quellcode:

if j=10 then
 begin
 maennchen.x:=maennchen.x+1;
 end;

Nein, dein Männchen verwaltet sich in ordentlichem OOP selber.

Wenn du läufst, gehst DU ja auch. Deine Abfrage da bewegt die "Straße" unter dem Männchen.

[edit]
Sry, 2. Seite nich gesehen ... :wall:
[/edit]

[s-off]

[OT]

Zitat:

Zitat von alzaimar

[...] nach Molwanien zu verlagern.

Sehr schön, kannte ich noch gar nicht - ich glaube, den Reiseführer werde ich mir tatsächlich mal zulegen; könnte glaube ich ganz lustig sein, den zu lesen

Zitat:

Impfungen vor dem Molwanien-Besuch sind nicht nötig, jedoch kann es nicht schaden, eigene Blutkonserven mitzubringen.

Danke für den ungewollten Tip :thumb:
[/OT]