Hallo,

hab nun schon einige erklärungen zu klassen gelesen (eher überflogen) aber eine frage stellt sich mir immer wieder:

warum instanziert/benutzt man eigene klassen ? welchen vorteil bringt das ? ich steig da noch nicht dahinter.


sorry für die doofe frage........

Guinnes

Dazu fällt mir ein:
- Kapselung von Daten und Methoden
- Vererbung (abgeleitete Klassen)
- -> einfacher zu entwicklen
- Nachnutzung
- Pflege
- Weitergabe von Code
...
bitte fortsetzen

Guinnes schrieb:

warum instanziert/benutzt man eigene klassen ?

Weil VB.Net eine objektorientierte Sprache ist und es gar keine Möglichkeit gibt, OHNE Klassen zu arbeiten? PS: Auch "Module" ist eine Klasse!

Es ist einfach übersichtlicher. Ab eiuner bestimmten Projektgröße ist es fakto gar nicht mehr möglich nicht-objektorientiert zu arbeiten. Es sei denn, man macht sich unnötig viel arbeit.

Naja, du brauchst nicht zwingend Klassen.
Du musst nicht zwingend eine Objektorientierte Sprache verwenden.
Du kannst auch strukturiert programmieren in Pascal oder C.

Klassen spiegeln halt alle Vorteile(Nachteile) der OOP wider.
Eine Klasse ist die Basis für eine OOP-Sprache.

Sinn dahinter ist es, Daten und Funktionen zu vereinen.
Das bedeutet, dass eine Klasse zum Daten halten verwendet wird, aber auch gleichzeitig die Funktionalität mitbringt, die Daten zu bearbeiten etc.

Ganz simple an einem Beispiel:



Die Daten (in dem Fall: Wer spricht?) sind seperat von der Funktion.
Das ganze in OOP:



Nun ist der Redner ein Objekt. Er hat einen Namen und eine Methode Reden. Außerdem ist die Methode Reden jetzt an ein Objekt vom Typ Sprecher gebunden.
Du benötigst also einen Sprecher zum reden. Außerdem kannst du problemlos mehrere Sprecher erstellen, und Sie werden alle reden können!
Im obigen Beispiel sind diese Dinge völlig unabhängig voneinander.
Man kann die Funktion von überall aufrufen.

Das ist natürlich runtergebrochen und mehr als primitiv, es soll aber die grundlegende Idee von OOP näherbringen.
Es gibt aber keinen Zwang, eine OOP Sprache zu lernen!

Mono schrieb:

Es gibt aber keinen Zwang, eine OOP Sprache zu lernen!

Ich glaube es ging dem Fragesteller weniger darum, ob er das unbedingt braucht / dass er vielleicht zu faul wäre.

Es ist hier denke ich ein Problem, dass bei mir in der FOS viele hatten: Sie verstehen den Ansatz der OOP nicht.

@TE

Einige haben ja bereits erklärt / gezeigt, warum man Klassen braucht.
Aber was heißt jetzt Kapselung? Vererbung? ...

Ganz einfach. Du hast eine Klasse Fahrzeug. Du überlegst, was haben sie ALLE gemeinsam? Sie können fahren. Sie können bremsen. (und weiteres) (=> Funktionen / Prozeduren)
Was ist bei allen Fahrzeugen unterschiedlich? Die Farbe? Die Anzahl der Räder? (Fahrrad / Auto?) (=> Eigenschaften)

Erstellst du eine Klasse Auto, kannst du nun sagen: Ich will ein blaues Fahrzeug, dass nenne ich AutoA. Die Farbe ist blau, es kann fahren, es kann bremsen.
Nun willst ein rotes Auto, du instanziierst eines mit der Eigenschaft Farbe = Rot. Es kann fahren, es kann bremsen.

In nicht-OOP hättest du vielleicht einen Struct o.ä. . Mit denen kann auch gearbeitet werden, aber du must deiner Methode sagen, welches Auto fährt. Das blaue oder das rote? Die Instanz hingegen weiß wer sie ist. Du sagst nur Bremse. Somit hast du da schon etwas vereinfacht.

Vererbung?

Was unterscheidet ein Fahrrad von einem Auto? Sie können beide Fahren und Bremsen. Ein Fahrrad hat aber keine Blinker und keinen Hubraum, ein Auto schon. Ein Auto benötigt keine Information, ob Stützräder dran hängen oder nicht.
Eine Farbe haben sie aber auch beide.

Du siehst, sie müssen all das haben, was Fahrzeuge könne, und haben jeweils ein paar Eigenheiten.

Dazu dient dann die Vererbung.

Eine Klasse Fahrrad erbt von Fahrzeug, und kann somit alles was ein Fahrzeug auch kann.
Eine Klasse Auto erbt ebenfalls.

Ein Auto hat nun aber keine Stützräder, ein Fahrrad keinen Hubraum.

Ich will jetzt gerade nicht drüber nachdenken, wie ich das in einer Prozeduralen Sprache darstellen müsste, dafür arbeite ich zu wenig damit bisher.



Aber ist nun der Sinn von Klassen, im genauen von Typen klar? (Jede Klasse ist ein Typ, auch Object ist eine Klasse, wobei jeder Typ von Object erbt und somit solche Dinge wie ToString oder GetHashCode.)

(Ein wenig lapidar erklärt und bestimmt gerade bei dem Gefasel mit Structen Fehler drinne, aber vielleicht hilft es zur Veranschaulichung, wofür diese Dinger gut sind...

Und noch etwas könne Klassen ganz hervorragend:
Sie können Events (Ereignisse) auslösen. So kann das Auto dem Programm z.B. selbständig mitteilen:"Huch, nu bin ich gegen einen Baum gefahren". Und der Baum (ebenfalls ein Object z.B. der Klasse Grünzeug) könnte seinerseits ein Event auslösen: "Ein Auto hat mich umgehauen, hat aber nicht wehgetan". Nun braucht das Programm nicht immerzu das Auto und den Baum fragen, ob was dagegengedonnert ist, sondern kann sich zurücklehnen und warten bis die sich gegenseitig verpetzen. Dann schickt das Programm das Auto in die Werkstatt und einen Gärtner zum Baum...

Fiel Fergnügen

Vatter

Vatter schrieb:

"Ein Auto hat mich umgehauen, hat aber nicht wehgetan"

Du bringst mich zum Schmunzeln...

Hier ein nützlicher Artikel noch: alt, aber Grundlagen, die Stimmen heute noch

Am besten liest du dich da mal ein, da ist auch das Beispiel mit der Vererbung drin (nur hier sind es dann Costumer, aber der selbe Grundsatz)

Klassen braucht man, wenn man mehrere voneinander unterscheidbare Objekte der gleichen Art haben will.
Klasse = Bauplan
Objekt (alias "Instanz") = das nach diesem Bauplan gebaute

Es gibt bereits mordsmäßig viele Klassen, und solange man nur die Buttons, Textboxen, Menüs und MenüItems aus der Toolbox zieht (sind alles Klassen), benutzt man das Zeugs, ohne vlt. genauer zu verstehen.

Also verstehen kannstedas erst, wenndedir ein konkretes Problem vornimmst, bei demde halt mehrere Objekte der gleichen Art brauchst - mw. ein Autorennen programmieren.

Nun, auch das schafft ein echter OOP-Noob, ohne was dazulernen zu müssen: Er nimmt einfach Pictureboxen, und nennt sie "Auto"

Aber ich stelle fest, ich progge auch nur sehr selten eigene Klassen - meist komme ich mit dem aus, wasses schon gibt, oder ich verwende Designer, die mir den KlassenCode schreiben (zb. der FormDesigner schreibt den KlassenCode einer von Form abgeleiteten Klasse) - was natürlich zum Lernen auch nicht so viel bringt.

meine richtigen eigenen Klassen sind meist ziemlich speziell, kannstedir jamal angugge:
Control mit beweglicher Figur - die DrawObject - Klasse (wobei im Sample wird ja nur eins davon genutzt - selbst das ginge prinzipiell auch mit einem Modul)
VersuchsChat - das ist ein ziemlicher OOP-Rundumschlag, mit einem Server, vielen Clients, Vererbung, Polymorphie und den ganzen Kram.

(Übrigens: auch ein Modul kann Events verschicken)

aha, etwas schlauer....

ist aber schon sehr "abstrakt" das thema....man müsste es wirklich mal an einem testprojekt selbst einsetzen.

nur nochmal zum klarstellen, ich möchte mich schon in vb.net weiter einlesen, bin also nicht zu faul / zu unwillig oder so.....

also gibt es "fertige" klassen und eigene ?!

Guinnes

Irrelevant in vb bzw .NET programmen funktioniert nichts ohne klassen

vorgefertigt sind zum beispiel die events in der Formclass(.vb) wie z.B. Form_Load(usw)

eine fertige Klasse: Textbox

eine eigene:Aber mir scheint wirklich nicht sinnvoll, dir hier die wesentlichen OOP- Konzepte vorzukauen, dass können andere besser: dieses Buch Lesen

@unknown: Ein Event ist keine Klasse - gugge Alles über Events

Die vorgefertigt in der Form.vb gespeichert sind oder nicht?

mir ist der unterschied zwischen klassen und events bekannt, ich mein damit nur das Form-Anwendung aus der Klasse der Form besteht.. ich kann mich wirklich schlecht ausdrücken

Klassen speichert man nicht, man speichert Daten.

Klassen werden per Code definiert. Textbox ist im Code der System.Windows.Forms.dll enthalten.

Guinnes schrieb:

also gibt es "fertige" klassen und eigene ?!

Solange Du Dich in der unmittelbaren .NET-Welt befindest, gibt es nur Klassen mit Daten, Prozeduren, Events.
Wenn Du ein wenig tiefer schürfst, landest Du bei der API.
Das sind Windows-Basisprozeduren, die in DLLs im Windows/System32-Verzeichnis liegen.
Diese kannst Du direkt ansprechen, ohne dass sie sich in einer Klasse befinden, allerdings musst Du sie innerhalb einer Klasse deklarieren, wodurch sie quasi eine Prozedur dieser Klasse werden.