Getter-Methoden

[antred]

Sorry, ich war noch bei C++. Von C# habe ich zugegebenermaßen nicht viel Ahnung.

 

[Rossibaer]

@antred: du nimmst mir die Pointe für SheepShaver...

@roker: Sorry, ich bin nur von C++ ausgegangen.

 

[antred]

'tschuldigung, aber ich glaube, das hätte er eh gewußt.

 

[Rossibaer]

Das was er schrieb, sah für mich eher aus, wie von seinem derzeitigen Lieblingstutorial über OOP abgetippt. Aber sei es drum ... War halt ein Versuch wert. Ich denke aber, dass ich es mir sicher mit ihm verscherzt habe.

 

[SheepShaver]

Ahem, die Zeit von Tutorials hab ich schon lange hinter mir gelassen. Ich bin seit nunmehr 10 Jahren professionell in der Java-Softwareentwicklung tätig. Natürlich hat das Spuren hinterlassen. Structs gibts in Java nicht (aus gutem Grund wie ich meine). Und ich bin immernoch der Meinung, dass Kapselung nur Vorteile hat, in Java sowieso. Man hat volle Kontrolle über den Zugriff, kann jederzeit die interne Struktur ändern ohne dass man tausend Klassen anpassen muss, es ist hilfreich beim Debuggen etc. pp. Einziger Nachteil: man muss Getter und Setter implementieren, aber das nimmt einem jede IDE ab.
In C# gibt es Structs, weiss ich. Haben da auch einen vorteil, da sie leichtgewichtiger sind und somit weniger Speicher verbrauchen, in C++ besteht technisch wie gesagt kein Unterschied und sind daher redundant.

 

[roker002]

@Rossibär und antred

ich glaube es ist von der Sprache unabhängig was Struct und Class für Speichermanagment bedeutet.

 

[antred]

@Rossibär und antred

ich glaube es ist von der Sprache unabhängig was Struct und Class für Speichermanagment bedeutet.

Da glaubst Du leider falsch.

 

[roker002]

also ich weis es sehr genau, dass structs als Value Type gelten, unabhängig von der Sprache, weil es ein Standard ist. Die Klassen sind Reference Type, wodurch diese in den Heap gespeichert werden und bis zum Programmende im Heap bleiben, egal ob die jetzt mit Null referenziert werden oder nicht! Hmm... ja mit C++ könnte mit Referenzierung bisschen anders laufen als in C# oder Java, weil C++ die Zeiger beherrscht. Aber die Sprachen haben sich ja nicht unabhängig von einander entwickelt. C++ ist ja auch nichts anderes als C mit erweiterten Funktionen und besseren Aufbau. Für C# oder ähnliche Sprachen gilt das gleiche. Man erweitert die Funktionalität der Sprache und Verbessert die Benutzerfreundlichkeit.

 

[antred]

Ich kann Dir 100%-ig versichern, daß 'struct' oder 'class' in C++ erst mal gar nichts darüber aussagt, in welchem Speicherbereich eine Instanz des structs bzw. der class angelegt wird. Das hängt in C++ einzig und allein davon ab, wie Du als Programmierer die Instanzen erzeugst.

struct A {}; // leeres struct ohne Member ... vollkommen äquivalent zu class A {};

void bla()
{
    A a; // auf dem Stack
    A* p = new A; // mit operator new angelegt ... also auf dem free store (oder wie er auch genannt wird, heap)
}

Du interpretierst da viel zu viel in die Tatsache hinein, daß C# und C++ beide ein C im Namen haben. Sicherlich hat C++ die Entwicklung von C# stark beeinflußt, und in den letzten Jahren hat möglicherweise sogar C# die weitere Entwicklung von C++ beeinflußt, aber das heißt noch lange nicht, daß Details der Sprache C# genau so auf die Sprache C++ zutreffen.

 

[roker002]

@antred

ne... du hast mich ganz falsch verstanden.

Ich mache mal ein Beispiel mit iPhone... naja Copy Paste gibts schon lange bei Win Mobile

also betrachte "deinen alten" iPhone als C Sprache... die hat wenig Funktionen die in den Standardbibliotheken eingebunden sind. Jetzt kommt die neue Version von iPhone Firmware... wow super, du hast jetzt copy and paste fest integriert in deine Standardbibliothek... ist doch super, du musst kein Managed Code dafür schreiben. Diese neue Version kannst du als C++ betrachten, weil du jetzt auch Klassen in deinen "C Code" benutzen kannst. Cool oder?

Natürlich ist der Beispiel total schlecht gewählt, aber man sieht deutlich, die neue Version ist nichts anderes als die alte mit neuen Funktionalitäten.

C# habe ich nur gewählt, weil es nichts anderes ist als die Vereinigung von C++ und Java. Es ist halt die "nächste Version", muss aber nicht heißen dass es auch die Bessere ist. Vista war auch nicht besser, sogar träger als die 7er Version. Naja das ist aber ganz andere Geschichte... ich verstehe auch nicht was es mit dem ganze Hype von 7er Version zutun hat. Der Kernel des Windows 7 ist ja von Vista und nicht XP.


PS: ups ich habe ja vergessen, dass die nächste Version von C++ eigentlich "D" ist. hehe

 

[antred]

Also, wenn das jetzt keine Nebelbombe war, dann weiß ich aber auch nicht.

Du hast hier ein paar Posts weiter oben die Aussage getroffen, daß "struct" unabhängig von der verwendeten Sprache eine gewisse Bedeutung für das Speichermanagement des Programms hat. Diese Aussage entspricht nicht der Wahrheit. Was zum Henker iPhones, D und der Windows 7 Kernel damit zu tun haben soll, ist mir ein Rätsel.

 

[Stefan_Sch]

Structs sind sowieso Bad Practice und ein C-Relikt

So ein Blödsinn! Willst du als nächstes auch Assembler als "Bad Practice" bezeichnen?

OOP ist ein Paradigma von vielen weiteren. Weder ist das eine, noch das andere Paradigma besser oder "überlegen".

Nix wird im Speicher anders behandelt. struct und class ist genau das gleiche ... EINZIGER Unterschied: beim struct ist per default die Zugriffstufe public, während sie in einer class per default private ist. Ansonsten gibt es Null Unterschied zwischen class und struct.

Toll erklärt Meister! roker002 sprach aber von C-Structs und nicht von C++-Structs. C-Structs sind einfache strukturierte Datentypen und keine Klassen, weil C keine OO Programmiersprache ist.

Und wie etwas im Speicher behandelt wird ist auch vollkommen irrelevant, im Speicher liegen nur Bytes. Du kannst soviel Objektorientierung machen wie du willst, am Ende führt der Prozessor die Instruktionen prozedural aus.

Ich kann Dir 100%-ig versichern, daß 'struct' oder 'class' in C++ erst mal gar nichts darüber aussagt, in welchem Speicherbereich eine Instanz des structs bzw. der class angelegt wird. Das hängt in C++ einzig und allein davon ab, wie Du als Programmierer die Instanzen erzeugst.

Das ist in der Tat richtig.

Du hast hier ein paar Posts weiter oben die Aussage getroffen, daß "struct" unabhängig von der verwendeten Sprache eine gewisse Bedeutung für das Speichermanagement des Programms hat. Diese Aussage entspricht nicht der Wahrheit.

Richtig. Ich wäre darüberhinaus generell vorsichtig darin Aussagen zu treffen, wie die Daten im Speicher abgelegt werden, vorallem bei interpretierten Sprachen, wie Java oder .NET. Der Rest ist Angelegenheit des Compilers und des Betriebssystems.

PS: ups ich habe ja vergessen, dass die nächste Version von C++ eigentlich "D" ist. hehe

D ist nicht die nächste Version von C++, sondern ein eigenständiges Projekt. Der Nachfolger ist C++0x, ein neuer Standard (Revision) für C++.

 

[Rossibaer]

@roker: Zuerst, ich habe mir nicht alles von dir durchgelesen, aber mach dich frei von den Paradigmen, die dir MS mit der Programmierumgebung des .Net Frameworks und Visual Studio aufzwingt. Es ist in C++ definitiv egal, ob nun struct oder class, beides das gleiche, einzig die default Sichtbarkeit für die Member ist in einem Fall public, im anderen Fall private. Desweiteren gibt es noch die Tatsache, dass ein struct von einem struct erben kann, aber nicht von einer class. Bei einer class ist es genau umgekehrt,d.h. class erbt von class aber nicht von struct. Das wars dann auch schon. Die Entscheidung ob es nun auf dem Stack oder Heap landet, trifft der Programmierer selbst. Da ist man nicht gebunden.

Im .Net Framework kämpfst du, statt gegen die Machine selbst, gegen eine virtuelle Machine, deren Regeln MS bestimmt. Eine Regel sagt, dass structs Wertetypen sind und auf dem Stack landen. classes sind dagegen Referenztypen und landen auf dem Heap. Aber nun das kuriose an dieser Trennung: Ein struct der einen String Member beinhaltet, landet zwar wegen der Regelung von MS auf dem Stack, aber der eigentliche String auf dem Heap und im Stack nur die Referenz auf den String. Verwirrend, oder? Am Ende weiß man nicht mehr, wo was ist. Aber wozu auch, ist ja so viel angenehmer... BTW: In C++ treffe ich jedesmal selbst die Entscheidung, was wo liegt.

Alles in allem gleitet das hier zu sehr vom eigentlichen ab.

Also bis zum nächsten Mal

Rossibaer

 

[SheepShaver]

So ein Blödsinn! Willst du als nächstes auch Assembler als "Bad Practice" bezeichnen?

OOP ist ein Paradigma von vielen weiteren. Weder ist das eine, noch das andere Paradigma besser oder "überlegen".

Dem stimme ich absolut zu. Da der Threadersteller aber offensichtlich eine OOP-Sprache verwendet (C# anscheinend), dann kann man in dem Kontext allerdings durchaus die Meinung vertreten, dass Klassen keine öffentlichen Membervariablen haben sollten.

 

[QXARE]

Sodale, ich hab das jetzt die letzten Tage verfolgt und hab mir nicht gedacht, dass das in so eine Diskussion ausartet. Jedenfalls bedank mich für die vielen informativen Links und Meinungen!

Grundsätzlich war die Frage nicht auf eine bestimmte Sprache bezogen, aber falls ihr es wissen wollt - bitte nicht hauen - hab ich zum Zeitpunkt der Fragestellung JS programmiert.

Ich bin jetzt zum Schluss gekommen, dass sich das Zugreifen auf Member innerhalb der Klasse über Getter nur dann lohnt, wenn diese nicht nur den Wert zurückgeben (und somit zusätzliche Arbeit verrichten) - Ausnahmen gibts aber immer wieder.

 

[Stefan_Sch]

Dem stimme ich absolut zu. Da der Threadersteller aber offensichtlich eine OOP-Sprache verwendet (C# anscheinend), dann kann man in dem Kontext allerdings durchaus die Meinung vertreten, dass Klassen keine öffentlichen Membervariablen haben sollten.

Diesen Standpunkt kann man natürlich vertreten, sofern man strikt in der OO Welt bleibt. Ich hatte bereits geschrieben das die Datenkapselung ein primäres Ziel beim Entwurf guter Objektklassen ist und man das auch möglichst einhalten sollte.

 

[antred]

Sodale, ich hab das jetzt die letzten Tage verfolgt und hab mir nicht gedacht, dass das in so eine Diskussion ausartet. Jedenfalls bedank mich für die vielen informativen Links und Meinungen!

Nur Programmierer können seitenlange Debatten über völlig triviale und für jeden normalen Menschen stinklangweilige Themen führen.

 

[Rossibaer]

Nur Programmierer können seitenlange Debatten über völlig triviale und für jeden normalen Menschen stinklangweilige Themen führen.

Das gilt auch für Chemiker, Physiker und Mathematiker. Achja den Steuerberater hätte ich beinahe
völlig vergessen...