spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Zitat von »Sacaldur«

Java ist aufgrund der primitiven Datentypen nicht _rein_ objektorientiert - Integer sind in Java keine Objekte (auch C++ ist nicht _rein_ objektorientiert)

	C#-Quelltext
1 2 3 4	class BoxedInt : Object { int i; }

• Eindeutig identifizierbar ist (eine Adresse hat)
  
• Einen Zustand (Daten) hat
  
• Ein Verhalten hat, also Operationen auf diesen Daten zur Verfügung stellt
  

Zitat von »dot«

Dass du einen int in ein System.Object packen kannst, liegt daran, dass C# (im Gegensatz zu Java) vernünftiges Boxing kennt.

Zitat von »dot«

Das ist dann gleichwertig mit sowas:

	C#-Quelltext
1 2 3 4	class BoxedInt : Object { int i; }

Nur dass .NET das eben implizit und automatisch für dich bastelt.

Zitat von »dot«

Das ist dann aber eben eigentlich kein int mehr.

Zitat von »dot«

Ein Objekt ist charakterisiert dadurch dass es

• Eindeutig identifizierbar ist (eine Adresse hat)
  
• Einen Zustand (Daten) hat
  
• Ein Verhalten hat, also Operationen auf diesen Daten zur Verfügung stellt
  

imo erfüllt ein int alle 3 Punkte.

	C#-Quelltext
1 2 3 4 5 6 7 8	static void Main(string[] args) { int integer = 32; Object objekt = integer; Console.WriteLine(integer.GetType()); Console.WriteLine(objekt.GetType()); Console.ReadLine(); }

Zitat von »Sacaldur«

das wird nicht automatisch gemacht, sondern ist (nicht unbedingt exakt so) im .NET Framework bereits vorhanden (die Klasse heißt Int32)

Zitat von »Sacaldur«

Zitat von »dot«

Ein Objekt ist charakterisiert dadurch dass es

• Eindeutig identifizierbar ist (eine Adresse hat)
  
• Einen Zustand (Daten) hat
  
• Ein Verhalten hat, also Operationen auf diesen Daten zur Verfügung stellt
  

imo erfüllt ein int alle 3 Punkte.

Quelle?

Zitat von »Sacaldur«

in Java erhält man niemals Zugriff auf die Adresse der einzelnen Objekte, geschweige denn man kann sie darüber ansprechen

Zitat von »Sacaldur«

ein int in Java und C++ erfüllt den 3. Punkt aber nicht

Zitat von »Sacaldur«

	C#-Quelltext
1 2 3 4 5 6 7 8	static void Main(string[] args) { int integer = 32; Object objekt = integer; Console.WriteLine(integer.GetType()); Console.WriteLine(objekt.GetType()); Console.ReadLine(); }

dieser Code gibt 2 Mal das gleiche aus
wäre der integer nach dem zuweisen an objekt kein integer mehr, dann hätte sich die Ausgabe verändert

Zitat von »Sacaldur«

dieser Code gibt 2 Mal das gleiche aus
wäre der integer nach dem zuweisen an objekt kein integer mehr, dann hätte sich die Ausgabe verändert

	C#-Quelltext
1 2 3 4	int integer = 32; Object objekt = integer; integer = 42; Console.Write(integer+ " " + objekt);

Zitat von »Sacaldur«

allerdings wird C dennoch nicht als objektorientierte Sprache bezeichnet, was dann an einem anderem Grund liegen muss
(und vielleicht liege ich ja mit meiner Meinung falsch, dass man (u. a.) die primitiven Datentypen aus Java nicht als Objekte Bezeichnen kann, vielleicht, weil ich es falsch gelehrt bekommen habe)

Zitat von »buggypixels«

Wie scharfsinnig das mit dem Listener zu erwähnen. Bei dieser Geschichte geht es NICHT um vernünftige Namen oder so etwas. Einen Manager nur anders zu benennen ist
damit nicht gemeint. Sondern vielmehr, dass es keinen Grund gibt für solche Klassen.
Seltsamerweise denken viele Leute bei OOP geht es NUR um Klassen und deren Methoden. Kaum einer denkt mal daran, dass Methoden auch außerhalb von Klassen existieren können und vor allem auch sollten.
In solch einem Manager sind oft Methoden drin, die eigentlich gar nicht in eine Klasse gehören. Darum die Aussage, keine Klassen mit "er". Natürlich gibt es Ausnahmen, da es ja englische Worte gibt, die auf er enden (siehe Listener, Player usw.).
In C gibt es den struct um Daten zu einer logischen Einheit zusammenzufassen. Das OOP Konzept stellt die logische Erweiterung dieser struct dar und fügt noch Methoden zu structs hinzu (darum kann man auch class und struct gleich verwenden). Das war seinerzeit die Idee hinter den Klassen und das grundlegende von C++.
Dennoch existieren weiterhin Methoden, die NICHT zu einer Klasse gehören. Da viele aber das Konzept nicht verstehen, entstehen plötzlich Manager/Helper etc. Klassen.
Aber nur weil sie denken, dass eine Methode schließlich in irgendeine Klasse rein MUSS. Das ist aber falsch.
Dieses Mißverständnis eisenhart durchgezogen führt dann zu Performance Problemen.
Also was shiroto schreibt, ist natürlich vollkommen falsch. Ein falsch angewendetes OOP Design kann zu Performance Problemen führen.
Grundsätzlich der Ansatz, ich fang einfach an und dann refactore ich bei Bedarf ist auch etwas schräg. Man sollte schon vorher ein bisschen drüber nachdenken.
Dann kann man sich direkt viel Refactoring ersparen. Aber dazu bedarf es vor allem viel Erfahrung.

Zitat von »dot«

Zitat von »Sacaldur«

	C#-Quelltext
1 2 3 4 5 6 7 8	static void Main(string[] args) { int integer = 32; Object objekt = integer; Console.WriteLine(integer.GetType()); Console.WriteLine(objekt.GetType()); Console.ReadLine(); }

dieser Code gibt 2 Mal das gleiche aus
wäre der integer nach dem zuweisen an objekt kein integer mehr, dann hätte sich die Ausgabe verändert

Interessantes Argument. Ich bin mir ehrlich gesagt nicht ganz sicher, wieso das so ist. Vermutlich ist es aber auf den Boxing-Mechanismus zurückzuführen. Unabhängig davon, was nun der genaue Grund sein mag, widerlegt das auch nicht meine eigentliche Aussage, dass int auch in Sprachen wie Java und C++ die Kriterien eines Objektes erfüllt.