spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Zitat von »Daedra22«

Ich bin etwas verwirrt, einer sagt es ist total falsch, ein anderer sagt es geht auch so. Ich bin ein kompletter Newbie deswegen bin ich für alles offen, ich hab komplett den Quellcode von Heiko im Kapitel 12 studiert, dieser hat genau das gleiche Verfahren verwendet, die Pointer hat er verwendet um auf Funktionen der Oberklasse zugreifen zu können.

Ich habe mich vielleicht schlecht ausgedrückt. Zu dem Beispiel, das dir Schorsch gegeben hat, war das die falsche Lösung. Ich gehe immer nach folgendem Ansatz vor. Kannst du dir vorstellen, das Klasse X eine Abwandlung von Klasse Y ist (ich meine hier wirklich vorstellen. Am Anfang würde ich mich nicht mit irgendwelchen UML Diagrammen o.Ä. herumschlagen), dann lass sie erben. Ist sie allerdings nur ein Bestandteil, mach sie zum Member.

Zitat von »Daedra22«

Die Verwendung von CKlasse als Klassennamen gehört doch zum guten Stil und wird als ungarische Notation bezeichnet, wenn ich mich nicht irre.

Die ungarische Notation ist out. Die kommt aus der Zeit, als eine IDE noch ein reiner Texteditor war. Keine Autovervollständigung, keine Tooltips beim drüber fahren und solche Sachen. Lässt sich meistens nur schwerer Lesen. Die einzigen Präfixe, die ich jetzt noch verwende, ist "m_" (für Member), "p" für Pointer und "_" für private Methoden.

Die ungarische Notation war eigentlich ein Missverständnis zwischen dem Erfinder und den Programmierern einer anderen Abteilung. Genauer gesagt zwischen Charles Simonyi und der Abteilung für Windows in Microsoft. Eigentlich war sie dafür gedacht, den Nutzen der Variable vorne ranzustellen. Zum Beispiel ein i für ein Array-Index, rw für eine Reihe (Die Notation ist in der Abteilung für Office entstanden), d für eine Differenz, usw. Es sind alles Ints, trotzdem ist der Prefix nicht gleich.
Die Abteilung für Windows hat das Wort "type" falsch verstanden, es meinte ja ursprünglich nicht den Datentyp. Und so haben wir heute noch lParam und wParam und einige weitere.
Vor Klassennamen ein C zu stellen bringt überhaupt nichts. Bei der Deklaration sieht man: "Ich erstelle hier eine Instanz einer Klasse". Aber wenn man die internen Datentypen auswendig weiß, erkennt man das auch so.

Den Kommentaren zur ungarischen Notation kann ich mich nur anschließen. Namen mit kryptischen Präfixen zu versehen, macht den Quelltext nicht übersichtlicher. Wichtiger ist, dass die Namen kurz und prägnant zum Ausdruck bringen, was sie beinhalten oder tun:

Oft gesehenes Negativbeispiel:



Mein Leidspruch zur Objektorientierung ist hier: "Du verstehst Objektorientierung, wenn Du weißt, wann du sie nicht verwenden solltest" [1]. Vererben sollten man m.M.n. nur, wenn man Polymorphie benötigt (virtual).

Mit Singletons sollte man m.M.n. auch sehr sparsam umgehen. Sie sollten nur dann eingesetzt werden, wenn es wirklich nur ein einziges Objekt des Typs geben darf (aktuell und in Zukunft). Sie sollen auf keinen Fall dafür eingesetzt werden um globale Variablen zu kaschieren. Das Beispiel mit der "Zeit" dient wahrscheinlich nur zur Demonstration (ich kenne das Buch nicht). Aber: Was spräche dagegen, dass es mehrere Zeiten gibt? Nichts? -> kein Singleton.

Persönlich habe ich mir folgende Regeln für Code-Formatierung auferlegt:

• CamelCase für Klassen
  
• tailing_underscore_ - für private Member-variablen
  
• UPPERCASE_WITH_UNDERSCORES - für globale Konstanten
  
• tailing_underscore_ - für private Member-variablen.
  
• Capitalized_Words_With_Underscores - für Funktionen, welche auf globale Variablen zugreifen (einfach, weil es so hässlich ist, dass man es am liebsten vermiede und als dicke Warnung für den Leser)
  
• lowercase_with_underscores - für alle anderen Namen
  

Grüße ... bwbg


[1]: "Stop writing classes!" Speziell für Python, lässt sich aber auch teilweise übertragen.