Alles in Klassen stecken?

[Shade Of Mine]

DocJunioR schrieb:

bevor man erste Aussage zewrreißen will. C++ ist keine objektorientierte Sprache, sondern eher ein hybride..

objektorientierung ist eine denkweise, keine sprache ist objekt orientiert.

sprachen bieten features an um die eine oder andere denkweise zu unterstuetzen. wenn wir uns zB java und javascript ansehen - beide Sprachen unterstuetzen mich bei objektorientierten denken, aber der Code der raus kommt ist komplett unterschiedlich.

aus OO sicht, macht es nicht mehr Sinn eine freie funktion als static in eine Klasse zu packen als sie in einen namespace zu packen oder frei stehen zu lassen. aus oo sicht ist das alles gleichwertig.

[DocJunioR]

ja.. aber in java beispielsweise ist es dir nicht wirklich möglich, programmcode außerhalb einer klasse zu halten..
c widerum enthält auch stilmittel zur strukturierten programmierung..

muss denn heute jeder meine verbalen unschärfen zerreissen?...

[tntnet]

Scav schrieb:

Ist es denn bei C++ "schöner" alles in Klassen zu stecken? Sollte ich mir das gleich angewöhnen?
Aktuell habe ich grad ein C++ Projekt, in dem ich vier Programmteile einfach in je einer .cpp Datei habe. Ich könnte daraus jetzt ohne große Probleme Klassen machen, aber sollte ich das?

Gruß

C++ ist eine tolle Sprache, weil es für viele Sachen Sprachmittel zur Verfügung stellt. Wenn eine Funktion eine Funktion ist, dann ist es in C++ eine Funktion. Ist es ein Objekt, mache ich in C++ eine Instanz einer Klasse draus. Eine Funktion in eine Klasse zu packen, nur weil es geht, macht das Programm nicht besser.

[Swordfish]

Shade of Mine schrieb:

objektorientierung ist eine denkweise, keine sprache ist objekt orientiert.

Schön gesagt Irgendwie hab' ich diese Art von "Diskussion" schon beim Posten meines ersten Beitrags in diesem Thread kommen sehen

cheers, Swordfish

[Gast]

Naja, diese Diskussion hatten wir auch schon länger nicht mehr

[otze]

Ich höre Xin schon schreien

[DocJunioR]

tntnet schrieb:

Eine Funktion in eine Klasse zu packen, nur weil es geht, macht das Programm nicht besser.

´

und schneller auch nicht ^^
aber es ist einfacher, wenn man es nur mit oop oder nur mit strukturierter programmierung (hat das ne abk.?) zu tun hat..

Ich muss regelmäßig den Salat anderer Leute aufräumen.. da freut man sich darüber, wenn mal einer nen bisken konsequent ist.

[rüdiger]

http://www.ddj.com/cpp/184401197

Scott Meyers schrieb:

I'll start with the punchline: If you're writing a function that can be implemented as either a member or as a non-friend non-member, you should prefer to implement it as a non-member function. That decision increases class encapsulation. When you think encapsulation, you should think non-member functions.

Surprised? Read on.

[Surprised?]

Jo, da hat er recht. Weniger Funktionen die an die Daten kommen == bessere Kapselung.

[mikey]

Wie es schon angesprochen wurde, kann man sich auch in C objektorientierten Code schreiben, weswegen Klassen in C++ in erster Linie nicht erforderlich sind, um objektorientiert programmieren zu können.

Wie es rüdiger bereits richtig zitiert hat, muss man manchmal sogar Funktionen aus Klassen auslagern, und diese global, besser in einem Namespace definieren, um bestimmten Konflikten aus dem Weg zu gehen. Und das bedeutet dann bei richtiger Modellierung keinesfall nicht-objektorientierten Code, nur weil sich ein paar Funktionen ausserhalb von Klassen befinden.

Objektorientierung kann man auf verschiedensten Weisen abbilden, völlig unabhängig von Klassen. Diese vereinfachen das ganze nur, und stellen ein paar andere Dinge wie Vererbung etc. bereit.

[was ist das]

http://www.ddj.com/cpp/184401197 schrieb:

else if (f needs type conversions
on its left-most argument)
{

Was soll das sein?
Kann mal einen Beispielcode für f needs type conversions on its left-most argument schreiben?

[DocJunioR]

Also als inzwischen auch Java-Programmierer bin ich da eben ein wenig komisch.
Wenn ich eine Methode habe, bei der es egal ist, ob sie in eine bestimmte Klasse kommt oder nicht, werde ich sie auch nicht unbedingt in diese schreiben. Das heißt aber nicht, dass sie nicht anderswo sinnvoll in einer anderen Klasse aufgehoben sein kann.

Klassen beschreiben Objekte und sämtliche Methoden, die mit diesen Objekten direkt zu tun haben, also Inhalte auslesen/setzen und streckenweise auswerten gehören dann dazu.

Ist so ungefähr wie das Problem mit den Löwen.. Die sollten imo zwar keine Methode mitbringen, sich fangen zu lassen, aber brüllen sollten sie schon selber. Das Einfangen wäre bei mir dann eher eine Frage des Käfigs..

[tntnet]

DocJunioR schrieb:

tntnet schrieb:

Eine Funktion in eine Klasse zu packen, nur weil es geht, macht das Programm nicht besser.

´

und schneller auch nicht ^^
aber es ist einfacher, wenn man es nur mit oop oder nur mit strukturierter programmierung (hat das ne abk.?) zu tun hat..

Ich muss regelmäßig den Salat anderer Leute aufräumen.. da freut man sich darüber, wenn mal einer nen bisken konsequent ist.

Mit Schelligkeit hat das gar nichts zu tun. Binär ist das kein Unterschied, ob eine Funktion frei steht oder als statische Member definiert ist.

Konsequent heißt für mich nicht zwangsweise alles objektorientiert. Auch wenn es wiedersprüchlich klingen mag, kann konsequent durchaus bedeuten, daß ich sowohl Objekte als auch frei stehende Funktionen habe. Die STL hat (mehr oder weniger) konsequent Container als Klassen und die algorithmen als frei stehende Funktionen. Ob das nun Oop ist oder nicht, ist mir so ziemlich egal. Hauptsache es ist gut strukturiert, verständlich und performant.

Übrigens: zählst Du Oop nicht zur strukturierten Programmierung ? Dann wäre Oop ja unstrukturiert .

[richtigstellung]

kann man sich auch in C objektorientierten Code schreiben

Das ist einfach eine Behauptung, die falsch ist.
Das Gefrickel mit structs ist eine Möglichkeit Klassen nachzumodelieren.
Objektorientierung umfasst aber eine Menge mehr.

[.filmor]

Was denn? Polymorphie und Vererbung bekommt man auch hin.

[Walli]

richtigstellung schrieb:

kann man sich auch in C objektorientierten Code schreiben

Das ist einfach eine Behauptung, die falsch ist.
Das Gefrickel mit structs ist eine Möglichkeit Klassen nachzumodelieren.
Objektorientierung umfasst aber eine Menge mehr.

Aha, was denn, was man Deiner Meinung nach mit C nicht hinbekommt? Da bin ich ja mal gespannt!

[DocJunioR]

tntnet schrieb:

Übrigens: zählst Du Oop nicht zur strukturierten Programmierung ? Dann wäre Oop ja unstrukturiert .

ich sag ja, ich muss nen kommunikationskurs machen..
oop ist eher nen aufsatz auf die strukturierte programmierung, ums noch ordentlicher und für laien noch verwirrender zu machen ^^

[fricky]

richtigstellung schrieb:

kann man sich auch in C objektorientierten Code schreiben

Das ist einfach eine Behauptung, die falsch ist.
Das Gefrickel mit structs ist eine Möglichkeit Klassen nachzumodelieren.
Objektorientierung umfasst aber eine Menge mehr.

jetzt sag aber nicht, dass structs noch funktionen enthalten sollten.

[Phoemuex]

was ist das schrieb:

http://www.ddj.com/cpp/184401197 schrieb:

else if (f needs type conversions
on its left-most argument)
{

Was soll das sein?
Kann mal einen Beispielcode für f needs type conversions on its left-most argument schreiben?

Wir schreiben einfach mal eine Klasse für komplexe Zahlen (ja, die gibt es schon in der Standardbibliothek, aber ein besseres Beispiel fällt mir gerade nicht ein):

class Complex
{
    public:
        Complex(double real, double imaginary = 0.0) //erlaubt Konvertierung von einfachen doubles zu Komplexen Zahlen
             : re(real), im(imaginary)
        {}
        Complex& operator+=(Complex const& rhs)
        {
            re += rhs.re;
            im += rhs.im;
            return *this;
        }
        //erste Möglichkeit zur Implementierung der (normalen) Addition
        Complex operator+(Complex const& rhs) const
        {
             Complex result = *this;
             result += rhs;
             return result;
        }
    private:
        double re, im;
};

Wenn man jetzt diesen Code kompilieren will:

int main()
{
    Complex a(1.0,1.0), b(2.0,3.0);
    Complex c = a + b;
    Complex d = a + 1.0;
    Complex e = 1.0 + a;
}

Kriegt man folgenden Fehler

error: no operator "+" matches these operands
       operand types are: double + Complex
      Complex e = 1.0 + a;

Das liegt daran, dass man keine Standardkonvertierungen benutzen und dann auf das Resultat eine Methode anwenden kann. Schreibt man die Addition jetzt aber so:

class Complex
{
    public:
        Complex(double real, double imaginary = 0.0) //erlaubt Konvertierung von einfachen doubles zu Komplexen Zahlen
             : re(real), im(imaginary)
        {}
        Complex& operator+=(Complex const& rhs)
        {
            re += rhs.re;
            im += rhs.im;
            return *this;
        }
    private:
        double re, im;
};

//Zweite Möglichkeit zur Implementierung der (einfachen) Addition
Complex operator+(Complex const& lhs, Complex const& rhs)
{
    Complex result = lhs;
    result += rhs;
    return result;
}

dann funktioniert der obige Code, weil man mit Standardkonvertierungen den double zu einem Complex umwandeln und das Resultat an eine const-Referenz binden kann. Weil man eben gerne diese Symmetrie hat, das sowohl double+Complex, als auch Complex+double funktionieren, ist es besser solche Operatoren, bei denen man für das linke Argument Konvertierungen erlauben will als (globale) non-member Funktionen zu schreiben.

Felix

[Richtigsteller]

Walli schrieb:

richtigstellung schrieb:

kann man sich auch in C objektorientierten Code schreiben

Das ist einfach eine Behauptung, die falsch ist.
Das Gefrickel mit structs ist eine Möglichkeit Klassen nachzumodelieren.
Objektorientierung umfasst aber eine Menge mehr.

Aha, was denn, was man Deiner Meinung nach mit C nicht hinbekommt? Da bin ich ja mal gespannt!

Das ist mit der Zeit richtig nervig Leute mal zum lesen zu animieren.

http://de.wikipedia.org/wiki/Objektorientierung