Ab wann setzt ihr eigene Klassen ein?

Werner Salomon

Klassenmachen schrieb:

Daher meine Frage, wann verwendet ihr Klassen?

Ich würde ganz naiv antworten: dann wenn ich es für angebracht halte.

Und es ist IMHO angebracht, wenn ein Haufen Daten auf Grund der Modellierung 'untrennbar' zusammen gehören und es auch nur Sinn macht mit einer ganz bestimmten Auswahl von Funktionen auf diesen Daten zu arbeiten. Und last but not least wenn dieser Daten-Haufen-mit-Funktionen auch noch eine Individualität besitzt.

Klassenmachen schrieb:

Wenn ich hundert Monster habe, dann habe ich einen Speicherbereich mit hundert zeigen auf die Struktur Monster und halt die Funktionen die mit diese Struktur umgehen.

dann betreibst Du bereits OOP, nur dass Du auf die Hilfsmittel von C++ verzichtest. Dazu gehören unter anderen Konstruktor und Destruktor.
Wenn Du meinst, dass man darauf verzichten kann, so schreibe doch mal eine einfach verkettete Liste - einmal mit Klasse und einmal ohne.

man muss natürlich aufpassen, was man tut. Ein Klassen-Design kann auch nach hinten losgehen; indem es nur mehr Code produziert und nichts bringt.
Klassen-Design bringt immer genau dann etwas, wenn man zumindest einen Teil der internen Komplexität vor dem Anwender 'verstecken' kann. D.h. für den Anwender sollte die Anwendung der Klasse immer einfacher sein, als mit dem besagten Haufen von Daten und Funktionen zu arbeiten.

Schau Dir doch mal diesen Code und diesen Code an - beide machen praktisch das selbe. Wäre auch nett, wenn Du das kommentieren würdest.
Vielleicht findest Du den Code ohne Klassen viel einfacher, dann solltest Du in so einem Fall auch keine verwenden.

Gruß
Werner

Ja, dann mache ich anscheinend bereits schon OOP und dann wird auch schon immer sehr viel OOP in C gemacht. Ich finde es halt in C einfacher fremden Code zu lesen, als wenn ich mich durch ein paar Klassen kämpfen muss und nur erraten kann wozu sie eigentlich gut sind.

STL ist sollte man nicht als Argument für Klassen sehen, da so etwas auch nur externe Funktionalität ist. Um dann zu vergleichen, müsste man schon in C das Beispiel dann mit der GLib oder zu aufzeigen.

Wenn ich die Fragen hier sehe mit Temp-Objekten, Const-Correctnes und die hundert Überladungen und Konstruktoren wird mir eher schlecht, als dass ich mich auf die Features freuen würde. C++ Code wird auch schnell kryptisch und ich behaupte mal dass man C-Programme in der Regel immer schneller verstehen kann wie irgendwelche C++-Konstrukte über mehrere Klassen verteilt und dann vielleicht noch mit Templates STL und alles bunt gemischt. Da blickt doch kaum ein Außenstehender ohne ordentliche Doku mehr durch und eine ordentliche Doku ist der absolute Ausnahmefall.

Na, aber wie hier schon geschrieben wurde, sollte man Klassen einsetzen wenn sie erforderlich sind und einen Vorteil bringen. Bei mir waren sie in den letzten Jahren noch nie erforderlich, aber das kann sich ja noch ändern.

otze

Das ligt daran, dass du an C gewöhnt bist, an C++ aber nicht. Ich finde C total unübersichtlich und kryptisch weil ich mir zu jeder Datenstruktur raus suchen muss, welche Funktionen nun dazu gehören.

Ja, da mag wohl viel Macht der Gewohnheit dabei sein. Ich mag halt einfache Sprachen. Aber ich betreibe ja C auch nur als Hobby und bin von Beruf Handwerker. Programmieren dient mir halt zur Entspannung nach der anstrengenden Arbeit.

Ich werde mich mal demnächst mit den Klassen beschäftigen, mir war halt nicht klar warum ich sie nutzen sollte, weil ich bis jetzt wunderbar ohne sie ausgekommen bin.

MichelRT

Klassenmachen schrieb:

STL ist sollte man nicht als Argument für Klassen sehen, da so etwas auch nur externe Funktionalität ist.

Wenn Du der Meinung bist, dann solltest du bei C bleiben.
Weil dann wirst Du über das Stadium C++ sei C mit Klassen und cin/cout nie hinauskommen.
Die STL gehört zu C++ und ist KEINE externe Bibliothek

cooky451

Wenn ich die Fragen hier sehe mit Temp-Objekten, Const-Correctnes und die hundert Überladungen und Konstruktoren wird mir eher schlecht, als dass ich mich auf die Features freuen würde.

const-correctness hat nichts mit C++ zu tun, die ist in C mindestens genauso wichtig. Klassen bieten dir vor allem 3 Vorteile (und noch mehr, aber ich denke das hier sollte überzeugend genug sein):

1. Kapselung. Du kannst Member private machen, was bedeutet du kannst die Zahl der Funktionen die auf diese Member Zugriff haben deutlich einschränken. (Von alle auf z.B. 5) Das verringert die Zahl der Stellen an denen man nach Fehlern in einer Klasse suchen muss deutlich. Nehmen wir nur mal als Beispiel einen vector in C:

int_vector v = create_new_int_vector(50);
v.size = 55; // oups, Objekt broken

Ist das ein Programmierfehler? Klar! Aber die versuchen wir ja gerade einzuschränken. In C++ ist dieser Fehler von außen schlicht nicht möglich, weil der Member "size" private wäre.*

2. RAII. Durch Konstruktoren und Destruktoren können Objekte ihre Ressourcen selbst verwalten. Typisches Beispiel für ein C-File-Wrapper:

class cfile
{
	FILE* handle_;

public:
	cfile(const char* filename, const char* mode)
		: handle_(fopen(filename, mode))
	{
		if (!handle_)
		{
			// throw something
		}
	}

	cfile(cfile&& other)
		: handle_(other.handle_)
	{
		other.handle_ = nullptr;
	}

	~cfile()
	{
		if (handle_ != nullptr)
			fclose(handle_);
	}

	// Methoden für read/write
};

int main()
{
	cfile file("test.txt", "rt"); // Ein file ist immer in einem gültigen Zustand
	file.read(...);

	std::vector<cfile> v;
	v.push_back(std::move(file)); // Und kann problemlos in Standardcontainer integriert werden.
	// Das file wird automatisch geschlossen 
	// sobald es aus dem Container entfernt, 
	// oder der Destruktor des Containers aufgerufen wird.
}

Und hier sieht man auch einen wie ich finde deutlich größeren Vorteil von RAII als dass man das eine fclose am Ende des Scopes nicht vergessen kann, dann die meisten erfahrenen C-Programmierer werden sowas wohl im Blut haben. Aber dass die Besitzverhältnisse mit Containern und letztlich im ganzen Programm über konsistent sind, das schafft man mit C einfach nicht. Dort musst du immer überlegen an welcher Stelle Ressourcen jetzt wieder frei gegeben werden. (Falls du es überhaupt schaffst dir einen generischen Container über Makros hin zu frickeln, wird dieser sich sicherlich nicht um die Freigabe der Ressourcen seiner Objekte kümmern können, das musst du wieder manuell machen.) Zudem musst du bei Funktionen die einen Pointer oder Ähnliches in C zurückgeben auch jedes mal nachgucken, wie du den Kram denn wieder frei gibst (falls du es nicht gleich vergisst und ein Leck produzierst ;)), in C++ kann man einfach das obige Pattern anwenden und alles gibt sich selbst frei, garantiert. (Spätestens wenn du Exceptions nutzen willst geht ohne RAII gar nichts mehr, aber das ist ein anderes Thema.)

3. Vererbung / virtual. Das ist wohl der uninteressanteste Vorteil, aber sollte man mal erwähnen. Das gibt dir im Prinzip Funktionspointer in structs die automatisch auf die richtige Funktion zeigen. Aber dafür gibt's genug Beispiele im Netz.

Für Vorteile von C++ im Allgemeinen sollte man wohl auch noch Templates, Operatorüberladungen, type-safety an kleinen Stellen, Lambdas, die umfangreichere und besser designte Standardlibrary, Exceptions, ... erwähnen, aber hier sollte es ja nur um Klassen gehen.

* Ja, man könnte natürlich einen Pointer nehmen, den casten und darüber das Feld verändern. Private ist eine reine Einschränkung beim Kompilieren, der Speicher wird nicht magisch geschützt. Aber es geht hier darum Flüchtigkeitsfehler und falsche Anwendung zu vermeiden, wer unbedingt auf einen privaten Member zugreifen will kann auch einfach das ein public: vor setzen.

STL ist sollte man nicht als Argument für Klassen sehen, da so etwas auch nur externe Funktionalität ist.

Da kann ich nur teilweise zustimmen - viele Konzepte der STL sind ja erst durch verschiedene Sprachfeatures möglich (Klassen/Templates). z.B. eben dass der vector seinen Kram selbst aufräumt wenn er out-of-scope geht.

MichelRT schrieb:

Klassenmachen schrieb:

STL ist sollte man nicht als Argument für Klassen sehen, da so etwas auch nur externe Funktionalität ist.

Wenn Du der Meinung bist, dann solltest du bei C bleiben.
Weil dann wirst Du über das Stadium C++ sei C mit Klassen und cin/cout nie hinauskommen.
Die STL gehört zu C++ und ist KEINE externe Bibliothek

Das ist mit als Programmierer doch völlig egal ob das nun eine externe Lib ist, oder zum Standard gehört. Ohne externe Libs kann man eh kaum arbeiten.

Wozu muss ich über einen bestimmtes Studium herauskommen? Es funktioniert doch alles wie es soll. Ich habe ein Problem, male mir ein paar Sachen dazu auf und suche Algos die mir helfen könnten. Dann entwickle ich die ersten Prototypen, sehe dabei wo größere Probleme auftreten können und das wird dann soweit verfeinert, bis ich keine Fehler mehr drin habe und meine Aufgabe erfüllt ist.

Dies alles funktioniert bei mir seit Jahren ohne eine einzige Klasse haben zu müssen und ich wollte in Erfahrung bringen, warum anderen es anscheinend nicht reicht und diese Leute Klassen unbedingt brauchen.

Ich denke, das wurde hier nun genug da gelegt. Alle angesprochen Probleme habe ich in meinen Programmen nie wirklich als ernsthaftes Problem angesehen. Wie gesagt, es funktioniert alles wie es soll und auch nach Jahren komme ich noch gut mit meinem Code von damals zurecht.

Klassen bleiben für mich wohl daher ein ziemlich sinnloses Konstrukt. Aber solange alles klappt, bleibe ich bei dem Motto: "Never change a runnning system"

Soll ich irgendwann mal Riesenprojekte mit mehreren Leute angehen, dann mögen Klassen durchaus Vorteile haben. Aber bei meinen Ein-Mann-Projekten, sind sie nur ein unnötiger Mehraufwand.

ScottZhang

Ja ist ja gut jetze, wir habens verstanden: Du findest Klasse(n) scheiße.
Mit der selben Argumentation kann man auch C vergessen und bei Assembler bleiben, und überhaupt wozu brauche ein Betriebssystem?

Das hat sich nunmal entwickelt, weil die Leute (endlich) anfingen Konzepte zu entwickeln und daraus zu abstrahieren. Das ist fast in jeder technischen, wissenschaftlichen Disziplin so. Klassen sind ein Abstraktionskonzept. Natürlich braucht man das nicht, aber es macht vieles eifnacher (sonst hätte man es garnicht für notwendig empfunden sowas zu entwickeln).

Ein Beispiel:
Es muss doch jedem klar sein, dass wenn ich z.B zwei (mathematische) Vektoren addiere, ich nicht jedesmal darauf hinweisen will das man dazu alle Komponenten addiert. Das nervt auf Dauer. Genau das kann man in C++ mit Klassen nachbilden.
Natürlich kann ich alle Komponenten getrennt behandeln, sie gehören aber logisch zusammen.

cooky451

Klassenmachen schrieb:

Aber bei meinen Ein-Mann-Projekten, sind sie nur ein unnötiger Mehraufwand.

Nein, sind sie nicht.

MichelRT

Klassenmachen schrieb:

Soll ich irgendwann mal Riesenprojekte mit mehreren Leute angehen, dann mögen Klassen durchaus Vorteile haben. Aber bei meinen Ein-Mann-Projekten, sind sie nur ein unnötiger Mehraufwand.

Du verwendest jetzt auch schon Klassen, nur hast Du es noch nicht gemerkt
In C++ ist auch ein struct eine Klasse, der Unterschied zu class ist nur, dass alle Member public sind. Es gibt aber Konstruktoren und Destruktoren, ...

@Klassenmachen
Beschäftige Dich intensiv damit, erfahre die Vorteile durch eigene Erfahrungen oder lass es einfach und bleib bei Deinem C-Gefrickel. Die ganze Diskussion ist nutzlos.

Gut, dann bleibe ich bei meinen "C-Gefrickel", denn es funktioniert für mich sehr gut und nur darauf kommt es an. Hätte ja sein können, dass mir Klassen was bringen. Ach ne, ich arbeite ja schon mit Klassen und OOP

@ScottZhang:

otze

benutzt du exceptions?

ScottZhang

Otze ist gut, der Typ trollt doch nur noch ...

sieht für mich so aus als würde der te - Klassenmachen - sich nicht mit allen sprachmitteln bzw. mit dem objektorientierten paradigma von c++ auseinander gesetzt zu haben. was mir spontan einfällt was durch klassen wesentlich verbessert wird:
- ausdrücken von logischen relationen wie komposition oder vererbung
- syntax des nutzers bzgl. konstruktoren / destruktoren / operatoren / methoden
- erheblich niedrigere fehleranfälligkeit dank RAII (man kann das konstruieren und das zerstören nicht "vergessen" (vergessen ist das falsche wort hier weil RAII auch ein segen für exceptionsafety ist))
- polymorphie, erheblich höhere modularität und flexibilität
- generik & metaprogrammierung
und sicher noch einige mehr...

aber ist mir eigentlich egal ob du deine programme fortan mit flexiblem und modernem c++-design oder mit "c++ with cout" programmieren möchtest.

ps.: ich würde zu gerne wissen, ob irgend eins deiner programme auch nur im geringsten exceptionsicher geschweige denn multithreading-fähig ist.

asdfsa schrieb:

- polymorphie, erheblich höhere modularität und flexibilität

lol, das Gegenteil ist der Fall.

ps.: ich würde zu gerne wissen, ob irgend eins deiner programme auch nur im geringsten exceptionsicher geschweige denn multithreading-fähig ist.

Wozu braucht er Exceptionsicherheit? Und mit Multithreading hat das gar nichts zu tun, alles, was keine globale Variablen verwendet, ist automatisch Multithreading-fähig.

cooky451

Klassenmachen schrieb:

Gut, dann bleibe ich bei meinen "C-Gefrickel", denn es funktioniert für mich sehr gut und nur darauf kommt es an.

Was war dann deine Frage? Wozu der Thread?

Klassenmachen schrieb:

Hätte ja sein können, dass mir Klassen was bringen.

Tun sie, siehe meinen Beitrag auf Seite 2.

buzzbuzzbuzz schrieb:

asdfsa schrieb:

- polymorphie, erheblich höhere modularität und flexibilität

lol, das Gegenteil ist der Fall.

hmm ne.

buzzbuzzbuzz schrieb:

ps.: ich würde zu gerne wissen, ob irgend eins deiner programme auch nur im geringsten exceptionsicher geschweige denn multithreading-fähig ist.

Wozu braucht er Exceptionsicherheit? Und mit Multithreading hat das gar nichts zu tun, alles, was keine globale Variablen verwendet, ist automatisch Multithreading-fähig.

ja, wozu braucht man exceptionsicherheit?
und so ein klassenloser prozeduraler zustandsautomat hat also keine globale variablen bzw. keinen globalen speicher?

Tut mal nicht alle so, als wenn man ohne Klassen und Design-Pattern keine Programme mehr schreiben kann.

otze

qwerty123 schrieb:

Tut mal nicht alle so, als wenn man ohne Klassen und Design-Pattern keine Programme mehr schreiben kann.

ja, aber dann in einer anderen Sprache. C++ ist dafür designed, mit Klassen benutzt zu werden. Haskell nicht, C nicht. Dewegen benutze Haskell und C wenn du keine Klassen benutzen willst. Dann kannste auch Programme ohne Klassen schreiben.