3. Gutes C++

Gutes C++

  • N

    http://www.c-plusplus.net/forum/viewtopic-var-t-is-168648.html

    rapso schrieb:

    ...
    Eine die wirkliche ein schoenes software design hat findest du aber eher nicht, weil die meisten menschen die eine engine schreiben aus dem c lager kommen(oder von solchen gelernt haben) und dann oft nichtmal die grundlegensten c++ dinge annehmen wollen wie z.b. ueberhaupt accessorfunktionen benutzen oder alles mit set/get benennen und nichts von ueberladung halten.

    Als ich das gelesen habe dachte ich rapso schreibt über mich :D. Bei mir ist das so. Ich fange mit Klassen an und Ende bei Klassen aus einer Mixtur aus Strukturen und Funktionene.

    Aussedem kann ich mir gar nicht vorstellen warum ich eine Methode, die einen Wert zurückgibt, nicht mit get benennen soll. Oder mit set wenn ich dem Objekt einen Wert übergeben will. Natürlich verwende ich auch gerne die STL. Aber das ganze noch sehr zaghaft.

    Doch ich frage mich was jetzt guter C++ Design ist. Muss ein Code gut designt sein? Reicht es nicht wenn man es verstehen/lesen kann. Vor allem versteht es der Compiler.

    Meine Frage, ist gutes C++ nur eine Sache der Ästhetik? Etwas das man anderen gerne zeigt. So wie man mit seinem neuen Sportauto, an einem schönen Sommerabend durch die Innenstadt fährt 🙄

    0
  • T

    Netzwerk-Latenz schrieb:

    Muss ein Code gut designt sein? Reicht es nicht wenn man es verstehen/lesen kann. Vor allem versteht es der Compiler.
    Meine Frage, ist gutes C++ nur eine Sache der Ästhetik? Etwas das man anderen gerne zeigt. So wie man mit seinem neuen Sportauto, an einem schönen Sommerabend durch die Innenstadt fährt

    guckst du: http://www.artima.com/weblogs/viewpost.jsp?thread=96404
    guter code...
    - can adapt to change
    - performs well
    - is error free
    - is as simple as possible
    - does what my customer needs
    alles andere ist doch zweitrangig...
    :xmas2:

    0
  • L

    @ten: du bist aber auch fleissig am rumposten, was?

    0
  • L

    edit: Ups, ich wollte in den anderen Thread posten. 😉

    0
  • K

    ich verstehe nicht, was an dem präfix get bzw. set so schlimm ist.
    wenigstens ist so eindeutig, was die funktion macht.

    0
  • E

    get bzw. set

    Das sind alles reine Modeerscheinungen. Man findet get... und set... in zahlreichen Lehrwerken für Einsteiger. Daher braucht man sich nicht wundern, wenn dies anschließend verwendet wird.

    0
  • ?

    Mit zunehmende Projektgröße neigt nicht OOP-Basierter Sourcecode dazu immer chaotischer zu werden. Besonderns wenn auch noch mehrere Programmierer zusammen arbeiten müssen und sich ein Projekt über längere Zeit erstreckt ist es nur eine Frage der Zeit bis auch der Letzte den Überblick verloren hat.

    Dabei steigt das Chaos nicht linear mit dem Sourcecode an, sondern eher proportional. Je älter ein solcher Code wird, desto schwieriger wird es Fehler zu finden, oder Änderungen vorzunehmen. Irgendwann läßt man das Programm dann nur noch laufen und hofft das nichts schiefgeht.

    OOP ist eine (mögliche) Antwort auf diese Problematik. Der Grundgedanke ist, daß man jedes Programm in möglichst kleine, in sich geschloßene Elemente Unterteilt. Jedes solche Element für sich betrachtet ist klein und übersichtlich, kann unabhängig vom Gesamtprojekt getestet und debugged werden.

    Sogar Änderungen an OOP-Projekten können bei sauberem OOp-Design durchgeführt werden ohne bestehenden Code verändern zu müssen, was bei prodeduralen Projekten nahezu unmöglich ist.

    Mit Ästhetik hat OOP also gar nichts zu tuen, sondern ist vielmehr ein Organisationssystem für Sourcecode.

    Die oben genannten Beispiele für getter/setter sind dabei ein sehr schönes Beispiel für absolut beschissenes OOP-Design, fallen also mehr unter die Kategorie wie man es nicht machen sollte. Grund? Nun, eine Klasse soll ein möglichst in sich geschlossenes Stück Sourcecode sein das mit seiner Umwelt (aka anderen Klassen) nur über Schnittstellen kommuniziert, dabei aber möglichst gar nichts über seinen inneren Aufbau preisgibt.

    Darum sollten Klassenvariablen z.B. grundsätzlich private sein. Gibt man dann aber sämtliche Variablen über getter/setter wieder nach außen hin zum Zugriff frei, ist das eigendliche Ziel des OOP ad absurdum geführt.

    Wenn ihr Auto fahrt, dann habt ihr ja auch keinen direkten Zugriff auf sämtliche Parameter des Motors, sondern ihr steuert den Motor nur indirekt über die euch zur Verfügung stehende Schnittstelle (gaspedal, Kupplung, Bremse). Alles was ihr über einen Motor wissen müßt ist über diese Schnittstelle definiert. Wie der Motor jetzt intern aufgebaut ist, obs nun ein Benziner oder Diesel oder elektromotor ist, ob er 2, 8 oder 50 zylinder hat... Vollkommen belanglos. es wäre sogar egal wenn euer Motor durch einen Komplett anderen ersetzt wird, die Bedienung der Schnittstelle ändert sich dadurch nicht.

    So ein Auto ist also nichts weiter als ein Beispiel für sauberes OOP-design. Hier erkennt man auch die Bedeutung gut definierter Schnittstellen. Stellt euch mal vor jeder Autohersteller würde gas, Kupplung und Bremse anders anordnen... Oder eine Automarke würde Gaspedale bauen, bei denen as Auto schneller wird je mehr man den Fuß zurückzieht...

    Ein anderes beispiel für angewandtes OOP-desing sind z.B. Bedienelemente technischer Geräte. Soe ziemlich jeder erkennt auf Anhieb einen Play, Stop oder Pause-Knopf (sowie die meisten Grundfunktionen). warum? weil es sich auch hier um eine klar definierte Schnittstelle handelt. Der Play-Knopf eines Videorecorders funktioniert dabei genau so wie der eine MP3-Players obwohl beide Geräte intern vollkommen unterschiedlich aufgebaut sind.

    Je mehr man darüber nachdenkt, desto mehr erkennt man wieviele Dinge unseres täglichen Lebens eigendlich OOP-Prinzipien folgen udn das schon seit einer viel längeren Zeit also es Computer gibt ;)...

    0
  • T

    schue schrieb:

    Die oben genannten Beispiele für getter/setter sind dabei ein sehr schönes Beispiel für absolut beschissenes OOP-Design, fallen also mehr unter die Kategorie wie man es nicht machen sollte. Grund? Nun, eine Klasse soll ein möglichst in sich geschlossenes Stück Sourcecode sein das mit seiner Umwelt (aka anderen Klassen) nur über Schnittstellen kommuniziert, dabei aber möglichst gar nichts über seinen inneren Aufbau preisgibt.

    auch reale objekte haben get/set funktionen. um es mal mit deinem auto-beispiel zu verdeutlichen: das gaspedal ist 'setDrehzahl()' und ohne 'getGeschwindigkeit()' würde so manch einer viele strafzettel kassieren...
    :xmas2:

    0
  • B

    schue schrieb:

    Dabei steigt das Chaos nicht linear mit dem Sourcecode an, sondern eher proportional.

    Hast du zufällig Wirtschaft studiert? 😃 SCNR 😉

    Wenn ihr Auto fahrt, dann habt ihr ja auch keinen direkten Zugriff auf sämtliche Parameter des Motors, sondern ihr steuert den Motor nur indirekt über die euch zur Verfügung stehende Schnittstelle (gaspedal, Kupplung, Bremse). Alles was ihr über einen Motor wissen müßt ist über diese Schnittstelle definiert. Wie der Motor jetzt intern aufgebaut ist, obs nun ein Benziner oder Diesel oder elektromotor ist, ob er 2, 8 oder 50 zylinder hat... Vollkommen belanglos. es wäre sogar egal wenn euer Motor durch einen Komplett anderen ersetzt wird, die Bedienung der Schnittstelle ändert sich dadurch nicht.

    So ein Auto ist also nichts weiter als ein Beispiel für sauberes OOP-design. Hier erkennt man auch die Bedeutung gut definierter Schnittstellen. Stellt euch mal vor jeder Autohersteller würde gas, Kupplung und Bremse anders anordnen... Oder eine Automarke würde Gaspedale bauen, bei denen as Auto schneller wird je mehr man den Fuß zurückzieht...

    Wenn du mal an so einem Auto rumschraubst, oder irgendwas an deiner Bremse einstellen willst, wie kommst du an die Bauteile ran? "getBremse()" kanns ja nicht sein. Nein, lass mich raten, du hast dafuer in der Autoklasse x-tausend Methoden, die all das machen, was man an einer Bremse so machen koennte... "Auto::macheBremseEmpfindlicher(delta), Auto::kontrolliereBremsscheibenabnutzung()".... oh, halt, ich hab's ganz vergessen, das sind ja eigentlich ein setter und ein getter, die heissen nur anders 😉 Du siehst, ganz ohne Getter und Setter wirds nicht gehen. Aber wie schon gesagt nur da, wo sie auch wirklich Sinn machen. Toll an setter/getter ist z. B., dass bei einem Bremse::getAbnutzung() mir vollkommen verborgen bleibt, ob die Abnutzung als Variable gespeichert ist, ob sie berechnet wird oder von einem Sensor abgefragt, DAS ist ein Vorteil von OOP.

    0
  • E

    Dabei steigt das Chaos nicht linear mit dem Sourcecode an, sondern eher proportional.

    linear proportional? 😃 :xmas2:
    get/set zeigen nur die Richtung des Informationstransfers an. Man benötigt in der Regel einen Zugang (in/out; set/get; poke/peek; ...) zu einem Objekt. Ansonsten ist es "autistisch".
    http://www.gotw.ca/gotw/070.htm

    0
  • D

    Erhard Henkes schrieb:

    Dabei steigt das Chaos nicht linear mit dem Sourcecode an, sondern eher proportional.

    linear proportional? 😃 :xmas2:
    get/set zeigen nur die Richtung des Informationstransfers an. Man benötigt immmer Zugang (in/out; set/get; poke/peek; ...) zu einem Objekt.
    http://www.gotw.ca/gotw/070.htm

    So sehe ich das auch. Der Präfix get und set zeigen einfach nur an, das ich bei dem einen etwas abfrage und bei dem anderen etwas setze. Es gibt ja noch den Präfix "is", für "ist etwas".

    0
  • L

    Was will man denn mit der Richtung? Man kann's doch überladen.

    0
  • J

    Kann man, muß man aber nicht. Es ist jedenfalls schwachsinnig zu behaupten wer's nicht tut schreibe automatisch schlechten Code.

    0
  • T

    ich mag getter und setter, so weiss man wenigstens, woran man ist. auch is und has haben ihren sinn.

    frag mich, warum man das anderes machen sollte bzw. anders nennen. im gegensatz zu solchen konstrukten wie der ungarischen notation find ich diesen "standard" wirklich sinnvoll.

    0
Anmelden zum Antworten