Vorteile von Klassen --> wo denn??
-
zum einen liegen die vorteile eben in der polymorphie und der vererbung zum anderen in der datenkapselung, denn was haben kleine winzige lokale variablen im bereich der globalen zu suchen?????
denn einen klasse kann konstruiert und nach gebrauch wieder zerstört werden um somit speicher wieder zu allokalisieren!
denn speicher ist immer rar und sollte nicht verschwendet werden.
zu dem thema funktionen: die lokalen variablen sind nach dem aufruf noch immer im speicher und verschwinden erst nach beenden des programms!
das ist bei klassen nicht der fall denn der speicherplatz den die variablen eingenommen haben wird sofort nach aufrufen des destruktors wieder freigegeben.[ 15.07.2001: Beitrag editiert von: Inferis ]
-
zu dem thema funktionen: die lokalen variablen sind nach dem aufruf noch immer im speicher und verschwinden erst nach beenden des programms!
ich bin eigentlich der meinung, das der speicher wieder freigegeben wird. also z.b.
int bla(void)
{
long mmm;return 0;
}hier wird mmm doch nach verlassen der funktion freigegeben. bin mir ziemlich sicher, aber eben nicht total images/smiles/icon_wink.gif
-
Hallo,
das eine:denn einen klasse kann konstruiert und nach gebrauch wieder zerstört werden um somit speicher wieder zu allokalisieren!
Da irrst du. Es werden Objekte (also Instanzen von Klassen) konstruiert und zerstört.
das andere:
lokale Variablen innerhalb von Funktionen werden beim Verlassen der Funktion vernichtet und belegen somit keinen Speicherplatz mehr (wie befi schon sagte).Nun zur Frage:
Klassen sind eine sehr reine Form der Datenkapsel. Dabei ist das Prinzip der Datenkapselung nicht neu. Schon in der prozeduralen Programmierung hat man versucht Daten und Funktionen zu kapseln. Dies führte zu gebilden wie z.B. die Abstrakte Datenstruktur (ADS) oder der Abstrakte Datentyp (ADT). Die ADS hat den Nachteil, dass nur eine feste Anzahl von Objekten eines solchen Typs angelegt werden kann. Der ADT erfordert einen sehr hohen Programmieraufwand.
Die Klasse ist eine objektorientierte Art der Datenkapselung. Jede Klasse definiert einen Typ. Eine Klasse ist relativ leicht zu programmieren und es können beliebig viele Instanzen einer Klasse erzeugt werden. Neben den Daten des Typ beinhaltet sie auch die Methoden die auf diesen Daten Sinn machen. Damit faßt sie also schon mal Eigenschaften und Verhalten zusammen. Durch die Sichtbarkeitseigenschaften (private, protected und public) stellt die Klasse die Möglichkeit zur Verfügung Code so zu gestalten, dass nur über ein bestimmtes Interface auf wichtige Daten zugegriffen werden kann. Der Vorteil liegt darin, dass unter Beibehaltung des Interfaces die gesamte Implementation verändert werden kann, ohne dass dies große Auswirkungen auf die Programme von Benutzern dieser Klasse hat.
Damit wird auch die Anwendung einer Klasse vereinfacht. Ein Benutzer braucht sich keinen Kopf um die Implementation einer Funktion zu machen, er kann sich vielmehr voll auf die angebotene Schnittstelle konzentrieren. Das Konstruktor/Destruktor Konzept greift dem Benutzer weiter unter die Arme. In der prozeduralen Welt muß der Benutzer meist Funktionen wie Initialize und Release (o.ä) explizit Aufrufen, damit ein Objekt in einem gültigen Zustand ist bzw. sauber vernichtet wird. Dieser Aufwand fällt bei der Benutzung von Klassen weg. Die Konstruktoren einer Klasse sorgen für die geordnete Erzeugung von Objekten. Vorher ist kein Zugriff auf ein Objekt möglich, was verhindert, dass eine Methode auf ungültigen Daten arbeit. Verläßt ein Objekt seinen Gültigkeitsbereich, wird automatisch der Destruktor aufgerufen und das Objekt wird sauber vernichtet.Nochmal kurz zusammengefaßt:
Die Klasse hilft bei der Umsetzung folgender oo-Prinzipien:
1. Encapsulation
2. Information hiding
3. Program to an interface not to an implementationSicher habe ich jetzt noch das eine oder andere vergessen, aber es ist schon spät und mein Gehirn arbeitet nur noch auf Sparflamme.
-
HumeSikkins hat ja schon fast alles erklärt, ich wills nurnochmal an mit nem Beispiel demonstrieren. Ich hab hier ein *.h von einer Menuklasse, die ich letztens für Konsolenprojekt geschrieben hab:
///////////////////////////////////////////////////////////////////////////////////// // Dateiname: menu.h ///////////////////////////////////////////////////////////////////////////////////// // Autor: Christian Roesch // // Erstelldatum: 27.03.2001 // letzte Aenderung: 27.03.2001 ///////////////////////////////////////////////////////////////////////////////////// // Info: Die Klasse Menu implememtiert einige Menufunktionen ///////////////////////////////////////////////////////////////////////////////////// #ifndef _MENU_H #define _MENU_H // includes #include "globals.h" // Klassen-Deklaration class Menu { public: Menu (int iSize); ~Menu (void); bool setPos (int iX, int iY); bool setText (int iNr, char* pcText=NULL); int show (void); int activate (void); protected: private: int m_iNrOf; int m_iActive; int m_iPosX; int m_iPosY; char** m_ppcText; int m_iMaxTextSize; bool m_bInitialized; }; #endif//_MENU_H class Menu; ///////////////////////////////////////////////////////////////////////////////////// // Ende der Datei: menu.h /////////////////////////////////////////////////////////////////////////////////////
1. Die Klasse merkt sich alle wichtigen Informationen, die man ihr per Konstruktor, setPos oder setText übergibt. Eine Funktion kann dies nicht leisten, da ja alle lokalen Variabeln wieder verloren gehen.
2. Die Klasse verwaltet den Speicher selbst. Es steht vorher nicht fest wieviel Speicher für den Text der Menupunkte gebraucht wird. Macht man ein setText besorgt sich die Klasse selbst den entsprechenden Speicher, den sie im Destruktor wieder freigibt.
3. Der Programmierer kann nicht aus Versehen Speicher freigeben oder über Arraygrenzen hinwegschreiben, das er keinen Zugriff auf die (privaten) Klassenmember hat.
4. Es ist vollkommen egal, wie die ganze Sache implementiert ist. Man muss nur die Methoden kennen.
5. Man könnte die Sache für eine Menu in der WinGUI oder in einem Spiel umschreiben, und sie später trotzdem noch auf die gleiche Weise aufrufen.
-
In der Sache hast du zwar recht, aber deine Argumentation ist IMO falsch. Nimm mal die stdio.h her. Das Objekt heißt FILE, der Konstruktor fopen(), der Destruktor fclose(), und die anderen Funktionen greifen auf dieses Objekt zu.
Dabei mußt du nicht wissen, wie FILE intern aussieht, oder wie die Funktionen implementiert sind. Wenn dort irgendwelcher Speicher gebraucht wird, kannst du sicher sein, daß die Funktionen sich den per malloc organisieren.
-
danke für die antworten.
vielleicht noch eine bemerkung zu den letzen antworten.
sicher, man muss nicht wissen, wie ein objekt funzt, man ruft die methoden auf und basta. aber ich habe auch mal in modula-2 programmiert (rein strukturierte sprache). dort gibt es auch so etwas wie eine kapselung. oder in pascal die units, die die benötigten funktionen beherbergen. innerhalb der extern compilierten unit - oder in modula-2 dem implementation-module - wird alles ohne objekte programmiert. der externe (unwissende) programmierer ruft dann, wie bei includierten klassen ja auch, nur die benötigte funktion auf. nur dass die ja herkömmlich, das heißt strukturiert, programmiert worden ist. ich will das thema hier nicht bis zum exzess treiben, aber so ganz 100%ig ist mir es noch immer nicht klar, und ich muss mich da nochmal reindenken. programmieren kann ich klassen etc. also schon, nur erschließen sich mir noch nicht so ganz alle vorteile.
-
Jo. Aber C-Programmierer bauen ihre Strukturen selten so auf und für mich ist nicht wichtig, was man in C tun kann, sondern was man tut. Und dort verwendet man im allgemeinen Strukturen MIT beabsichtigten Zugang zu den Elementen.
Und fclose wird natürlich nicht automatisch aufgerufen. Für mich ist ein abschliessender Destruktor/Funktionsaufruf eine Art Codeverdopplung - zumindest sind die Auswirkungen ähnlich.cu
-
Hallo,
einen aspekt habt ihr bis jetzt ganz außer acht gelassen!
das thema sollte nicht was ist der vorteil von klassen, sondern was ist der vorteil der oop heißen images/smiles/icon_wink.gif...wenn man tools wie z.b. rational rose (UML) einsetzt kann man:
- die ganze konzeptarbeit auf papier erledigen
- dem auftraggeber auf deutsch erklären was sein prog können wird und was net so einfach zu machen ist
- und sich dann das codegerüst automatisch erstellen lassen...
...soviel dazu von meiner seite images/smiles/icon_biggrin.gif
-
Das stimmt. OOP kommt der 'natürlichen' Denkweise viel näher als die mathematisch inspirierte strukturelle Programmierung, so kann nan, finde ich, viel besser planen.
Außerdem, ein Objekt besitzt ja immer Eigenschaften und Fähigkeiten zur Bewältigung eines Problems. Idealerweise übernimmt ein Objekt (eine Klasse) genau eine Aufgabe und reicht die bearbeiteten Daten an das nächste Objekt weiter. So kann man logischerweise viel besser Fehler erkennen, und es ist, wie oben beschrieben, sicherer. Eine Funktion bietet das nicht, da muss man immer die gesamte Funktion (um-)schreiben.
Ein weiterer Vorteil in meinen Augen sind die Konstruktoren und Destruktoren, so kann man bestimmte Vorraussetzungen schaffen, wie es der Programmierer selbst wollte.
-
Ist eigentlich alles ganz kurz zu sagen:
Wenn ich eine Variable/Funktion private mache, garantiere ich dem Nutzer der Klasse, dass er sich um diese Members gar keine Gedanken mehr machen muss. Die protected-Dinge muss er noch mal anschauen, um sie in abgeleiteten Dingen dem nächsten dann endgültig zu 'entsorgen'.
Public muss immer kräftig dokumentiert werden. Und wer mag das schon.