Gutes C++
-
edit: Ups, ich wollte in den anderen Thread posten.
-
ich verstehe nicht, was an dem präfix get bzw. set so schlimm ist.
wenigstens ist so eindeutig, was die funktion macht.
-
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.
-
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 ;)...
-
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:
-
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.
-
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
-
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.htmSo 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".
-
Was will man denn mit der Richtung? Man kann's doch überladen.
-
Kann man, muß man aber nicht. Es ist jedenfalls schwachsinnig zu behaupten wer's nicht tut schreibe automatisch schlechten Code.
-
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.