Verständnisfragen zur OOP

Dingo · Beiträge: 64 Erhaltene Danke: 1

Hallo an alle!

Ich hänge gerade an den Grundlagen von C# und habe noch ein paar Verständnisfragen zur OOP, da die Beispiele für mich etwas weit hergeholt sind und ich diese nur in den Grundzügen verstehe. Ist ein etwas längerer Text, doch hoffe ich das ihr einem Anfänger ein wenig helft es zu Verstehen.

Bisher habe ich alles mit Variablen, primitiven Dateitypen und auch Methoden so weit, so guterstanden.

Jedoch bei Namensraum, Klassen und Objekten laufe ich gedanklich immer wieder gegen eine Mauer. Habe nun schon einige Bücher und einige Forenbeiträge gelesen, aber verstehe es einfach nicht. Ich hab mir jetzt alles noch mal in Ruhe vorgenommen und mir selbst eine Erklärung mit Beispielen gemacht, die eher meiner Denkweise entsprechen und wollte mal Fragen, ob ich das nun so richtig verstanden habe.

Methoden:

Methoden dienen dazu wiederkehrende Aufgaben bzw. Probleme zu lösen. Zum Beispiel eine simple Berechnung in einer Methode abarbeiten und mir über „return“ einen weiterverwenden Wert zurück geben oder eben eine Ausgabe erledigen.

Zum Beispiel:

markieren

C#-Quelltext

1:
2:
3:
4:
5:
6:
7:

double versandkosten(double preis) {
     return 2.0 * anzahl;
}

void ausgabe() {
     Console.WriteLine(„Dies ist eine Ausgabe“);
}

namespace:

Namensräume sind Hüllen in denen verschiedene Klassen und Interfaces unter dem selben Gesichtspunkten zusammengefasst werden. Hier finde ich das Java Wort Packages besser, weil greifbarer.

Beispiel wäre demzufolge:

markieren

C#-Quelltext

1:
2:
3:
4:
5:
6:

namespace Spieler {
     class Bewegung {}
     class Verteitigung {}
     class Angriff {}
     class Schaden {}
}

Der Spielercharakter hätte nun seinen eigenen Namensraum mit den für ihn nutzbaren Klassen. Neben diesen Namensraum gibt es noch einen Namensraum namens „Gegner“:

markieren

C#-Quelltext

1:
2:
3:
4:
5:
6:

namespace Gegner {
     class Bewegung {}
     class Verteitigung {}
     class Angriff {}
     class Schaden {}
}

Es sind wieder die selben Klassen zu finden, jedoch in einem anderen Namensraum mit einem Bezug auf den Gegner und nicht auf den Spieler. Beide Räume sind von einander getrennt, außer man greift auf sie durch „using“ zu.

Klasse:

Eine Klasse ist eine Zusammenfassung von Objekten mit gleichen Merkmalen.

Ich nehme hier noch mal den Spieler zur Hilfe als Beispiel:

markieren

C#-Quelltext

1:
2:
3:
4:
5:
6:

class Bewegung {
     methode vorwärtsLaufen();
     methode rückwärtsLaufen();
     methode linksLaufen();
     methode rechtsLaufen();
}

Von Klassen können nun auch Kinder abgeleitet werden, es wird vererbt, sagt man ja.

Eine Vererbung wäre nun zum Beispiel:

markieren

C#-Quelltext

1:	class Rennen : Bewegung

Rennen würde nun also alles von Bewegung erben, das einzige was nun verändert werden würde, wäre die Laufgeschwindigkeit, ansonsten muss er sich ja immer noch vorwärts, rückwärts, ect. Bewegen, was er ja von Bewegung geerbt hat..

Objekte:

Objekte sind Dinge um uns herum, sie können Fähigkeiten (Methoden) und Eigenschaften (Variablen) besitzen. Das Objekt Kugelschreiber hätte nun die Eigenschaften (Variablen) 20g schwer, blau und 12 cm lang. Das Objekt Kugelschreiber hätte nun die Fähigkeit (Methode) zu schreiben.

Bis hier hin nun alles ja ganz logisch, aber wann mache ich das:

markieren

C#-Quelltext

1:	Gegner newBoss = new Gegner();

Was bringt es mir ein Objekt zu erzeugen? Erzeuge ich damit wie im Beispiel aus der Klasse Gegner einen neuen Kämpfer oder wie ist Objekt erzeugen nun zu verstehen? Wann nutze ich es sinnvoll an?

Nebenbei das hier wäre nun ein Construlor oder?

markieren

C#-Quelltext

1:	Gegner newBoss = new Gegner();

Static:

Die Erklärung zu „static“ hab ich bisher gar nicht verstanden, wann nutzt man es und für was ist es sinnvoll?

This:

Hier herrscht auch ein Verständnissproblem. Wann und wie nutze ich das und auf was greift es zu?

Instanz:

Instanzen sind Objekte, verstehe ich das richtig? Sprich es ist nur ein anderes Wort für ein und das selbe?

Vielen Dank schon einmal für die Hilfe!

Moderiert von Th69: C#-Tags hinzugefügt
Moderiert von Th69: Titel geändert (war "Fragen eines C#-Anfängers").

Delphi-Laie · Verfasst: So 05.03.17 18:29

Dingo hat folgendes geschrieben :

Instanzen sind Objekte, verstehe ich das richtig? Sprich es ist nur ein anderes Wort für ein und das selbe?

Instanzen sind Variablen eines Objekttypes, einer Objektklasse. Mit leichtem Zögern kann ich diese Frage bejahen

Dingo · Ehemaliges Mitglied Erhaltene Danke: 1

- Nachträglich durch die Entwickler-Ecke gelöscht -

OlafSt · Verfasst: Mo 06.03.17 09:38

Delphi-Laie hat folgendes geschrieben :

Dingo hat folgendes geschrieben :

Instanzen sind Objekte, verstehe ich das richtig? Sprich es ist nur ein anderes Wort für ein und das selbe?

Instanzen sind Variablen eines Objekttypes, einer Objektklasse. Mit leichtem Zögern kann ich diese Frage bejahen

Ich nicht. Nicht einmal mit etwas zögern.

Das supersimple Beispiel mit dem Clown macht es deutlich: public class Clown ist die Klasse. Es ist nur die Definition gemeint. Bei Clown clown1 = new Clown(); ist clown1 eine Instanz der Klasse Clown. Genauso wie etwas weiter unten clown2 ebenfalls eine Instanz der Klasse Clown ist.

Ergo: Klasse -> Nur die Definition, quasi ein Variablentyp. Ähnlich wie Integer oder Double.
Instanz -> Tatsächlich existierende Variablen einer Klasse.

_________________
Lies, was da steht. Denk dann drüber nach. Dann erst fragen.

Dingo · Ehemaliges Mitglied Erhaltene Danke: 1

- Nachträglich durch die Entwickler-Ecke gelöscht -

Ralf Jansen · Verfasst: Mo 06.03.17 11:05

Zitat:

Instanzen sind Variablen eines Objekttypes, einer Objektklasse. Mit leichtem Zögern kann ich diese Frage bejahen

Zitat:

Instanz -> Tatsächlich existierende Variablen einer Klasse.

Man könnte bei euren Beschreibung den Eindruck gewinnen Variablen wären die Instanzen einer Klasse. Möglicherweise habt ihr Variable umgangssprachlich verwendet aber Variablen haben in der Programmierung natürlich eine konkrete Bedeutung. Eine Variable ist nur ein Verweis auf etwas. Dieses etwas kann eine Instanz sein muß aber nicht.

markieren

C#-Quelltext

1:	Clown clown = null;

Der Verweisegedanke ist wichtig. Mehrere Variablen könnten ja auch auf die gleiche Instanz einer Klasse verweisen.

markieren

C#-Quelltext

1:
2:

Clown clown = new Clown();
Clown clown2 = clown;  // 2.ter Verweis aber gleiche Instanz

Ergo eine Variable ist keine Instanz von etwas. Eine Variable ist ein Verweis auf etwas.

Dingo · Beiträge: 64 Erhaltene Danke: 1

Vielen Dank für die Ausführlichen Hilfe, jetzt versteh ich die Zusammenhänge langsam!

Ralf Jansen · Verfasst: Mo 06.03.17 14:34

Zitat:

namespace:
....
Es sind wieder die selben Klassen zu finden, jedoch in einem anderen Namensraum mit einem Bezug auf den Gegner und nicht auf den Spieler. Beide Räume sind von einander getrennt, außer man greift auf sie durch „using“ zu.

Die Klassen in den verschiedenen Namespaces haben technisch erstmal nichts miteinander zu tun. Logisch stellst du sie möglicherweise in Beziehung oder durch andere technische Maßnahmen wie der Implementierung der gleichen Interfaces oder der Ableitung von einer gemeinsamen Basisklasse. Aber nur weil sie in verschiedenen Namespaces dann gleich heißen wäre das erstmal nur Zufall aber kein Zusammenhang in irgendeiner Weise.

Durch "using" bekommst du keinen Zugriff du machst den Zugriff nur einfacher. Vergleichen wir das mit üblichen Namen von Personen. Der Einfachheit meinen

Überall Ralf Jansen zu schreiben ist aufwendig viel einfacher wäre einfach nur Ralf zu sagen weil es hier ja auch eher selten zu Namenskollisionen mit anderen Ralfs kämme. Programmiertechnisch hieße das wir definieren vorher ein using Jansen; um dann im folgenden einfach immer nur Ralf sagen zu müssen. Genau das ist die Kernaufgabe des using. Der Name einer Klasse ist eigentlich immer inklusive seines Namespaces. Bei dir also eigentlich Spieler.Bewegung bzw. Gegner.Bewegung. Und weil das aufwendig ist das immer auszuschreiben kannst du halt sagen using Spieler, am besten nur an Stellen wo du nicht auch Gegner brauchst, um im folgenden einfach Bewegung sagen zu können.

Ergo Namespaces sind dazu da eindeutige Namen für Klassen zu bekommen. Ab einigen Tausend Klassen wie zum Beispiel im .Net Framework wird es nämlich schwer die eindeutig zu halten ohne sie künstlich mit Bestandteilen zu ergänzen die wenig hilfreich wären. "Using" hilft dann das man denn vollen Namen einer Klasse nicht immer nennen muß sondern die Kurzfassung reicht solange die dann noch eindeutig sind. Würdest du in deinem Beispiel sowohl using Gegner; also auch using Spieler; in einer Datei verwenden und dann versuchen die Klasse Bewegung anszusprechen (also die Kurzfassung ohne Namespace angabe) würde dir der Compiler das anmeckern mit dem Hinweis das der Name der Klasse so nicht eindeutig bestimmbar ist.

Delphi-Laie · Verfasst: Mo 06.03.17 14:38

Gut, wenn man es reduktionistisch betrachtet, dann ist ein Objekt nur ein Zeiger, eine Speicheradresse, also eine Integerzahl. Doch hilft eine solche Antwort dem Fragesteller?

Nun bin ich mir auch nicht sicher, ob Objekte in allen Programmiersprachen Zeiger sind. Ist es nicht auch grundsätzlich möglich, daß Variablen von Objekttypen /-klassen "echte" Variablen sind, ohne diese elenede Verzeigerung?

Ich habe es so gelernt, daß Objekte zunächst als Typen (in etwas ausführlicher Form als Klassen) deklariert werden und jede Variablendeklaration (-definintion?) davon eine Variable, eine Instanz ist. Schließlich steht ja das Schlüsselwort "var" auch vor den Objektvariablen, und der Typ ist zudem kein Pointer, sondern eben der des Objektes! Was daran nun so grottenfalsch sein soll, verschließt sich mir.

jaenicke · Verfasst: Mo 06.03.17 15:22

Delphi-Laie hat folgendes geschrieben :

und jede Variablendeklaration (-definintion?) davon eine Variable, eine Instanz ist.

Das ist der große Unterschied. In zwei unterschiedlichen Variablen kann ein Verweis auf die gleiche Instanz bzw. das gleiche Objekt liegen. Deshalb ist das nicht gleichbedeutend. Denn beide Variablen verweisen nur auf die gleiche Instanz im Speicher, sind selbst aber nicht gleich.

Ralf Jansen · Verfasst: Mo 06.03.17 15:22

Grottenschlecht ist sicher nicht das was ich sagen wollte. Spätestens wenn wir uns mit Folgeerklärungen rumschlagen also z.B. den Unterschied zwischen struct und class oder sprachunabhängiger benannt zwischen Referenz- und Value-Typen wird es schwer. Oder auch die Frage wie genau jetzt der Transport einer Instanz eines Klasse über einen Methodenaufruf funktioniert (wann Referenz wann Kopie und warum ...) wird es schwer das klar zu machen wenn man vorher bei einem Anfänger ein Gedankenmodell aufgebaut hat das eine Gleichsetzung von Variablen und Instanzen beinhaltete. Ja beim lehren kann man nicht immer gleich den Lernenden mit allen Details konfrontieren und man hat immer den Punkt des "Lügens für Anfänger" und wie weit man das treibt. Hier halte ich es aber für relevant diesen Unterscheidung frühzeitig zu benennen da er nachträglich schwer aus dem Kopf zu bekommen ist. Zumindest ist das meine Annahme, mein eigener Lernprozess disbezüglich ist schon zu lange her

Zitat:

Nun bin ich mir auch nicht sicher, ob Objekte in allen Programmiersprachen Zeiger sind.

Zeiger sind ein reines Implemetierungsdetail ob hinter etwas einer steckt oder nicht sollte irrelevant sein. In allen mir bekannten OO Sprachen wird aber eine Variable ein Verweis/Referenz sein und nicht das Ding an sich. Valuetypen tun nur so als ob es diesen direkten Zusammenhang gäbe (wie ignorieren hier auch wieder besser das Implementierungsdetail der Unterscheidung von Heap und Stack).

Dingo · Beiträge: 64 Erhaltene Danke: 1

Ich merk schon, ich merk schon, ich hab noch viel Arbeit vor mir, um alles zu verstehen.^^

Also das "using" nutzt man dann sozusagen auf Deutsch aus Gründen der "Faulheit"?!

Ich könnte schreiben:

markieren

C#-Quelltext

1:	System.Console.WriteLine();

Einfacher und kürzer wäre es aber wenn ich oben einen Verweis setze:

markieren

C#-Quelltext

1:	using System;

Und im Quellcode an sich nur noch schreibe:

markieren

C#-Quelltext

1:	Console.WriteLine();

Verstehe ich das so richtig?

Dann hätte ich noch einmal eine Verständnisfrage zu dem kleinen Miniabschnitt hier:

markieren

C#-Quelltext

1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
15:
16:
17:

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;

namespace Lektion2
{
    class Program
    {
        static void Main(string[] args)
        {
            Console.WriteLine("Erste Ausgabe des Programms in Lektion 2");
            Console.ReadLine();
        }
    }
}

Wenn ich es verstehe wäre nun:

System = Namespace, genau so wie Lektion2
Console = Wäre damit eine Klasse von System
WriteLine = Wäre demnach eine Methode von Console, die wiederrum zu System gehört

Passt das so?

Und vielen Dank für die Hilfe, ihr helft mir echt weiter!!!

Moderiert von Th69: B- durch C#-Tags ersetzt

Ralf Jansen · Verfasst: Di 07.03.17 11:44

Zitat:

Verstehe ich das so richtig?

Ja.

Zitat:

Passt das so?

Ja .. sprachlich vielleicht nicht ganz. Bei Namespace spricht man eher davon das sich etwas in ihm befindet. Man würde alse eher sagen "Die Klasse Console befindet sich im Namespace System". Dein Satz ist da nicht falsch klingt aber zumindest unüblich.

Übrigens dein Beispiel enthält nebenbei einen sinnvollen Einsatz von static.

Dingo · Beiträge: 64 Erhaltene Danke: 1

Super, endlich verstanden.

Zu "static", nun ja, static main besagt ja, dass dies die erste Methode ist, die beim Programmstart initialisiert wird.

Würde ich nun andere Methoden nun auch mit "static" versehen, würde die dann auch zum Programmstart mit los legen?

jfheins · Beiträge: 918 Erhaltene Danke: 158 Win 10 VS 2013, VS2015

Nein ...

Es ist so: Der Anfang des Programms wird durch den Methodennamen vorgegeben - die Methode muss immer Main heißen.
Nun ist es so, dass ganz am Start ja noch keine Objekte existieren. Klassen ja, aber eben noch keine Objekte.

Wenn Main() nun eine normale Methode der Klasse Program wäre, dann müsste man die ja erst instanziieren! Das widerspricht aber dem Gedanken, dass Main() zuerst aufgerufen wird. Daher macht man Main() static, sodass die Methode auch direkt auf die Klasse aufgerufen werden kann.

Ohne static wäre das so ein Henne-Ei-Problem: Um Objekte zu erzeugen muss das Programm laufen und um das Programm laufen zu lassen müsste man Objekte erzeugen.

Hier ist noch eine SO-Antwort dazu: stackoverflow.com/qu...hould-main-be-static
Man kann also auch eigenen Code vor Main() ausführen. Aber es wurde damals einfach so definiert, dass es eine statische Main-Methode geben muss ;-)

Zitat:

Main wird in einer Klasse oder einer Struktur deklariert. Main muss statisch sein und darf nicht Öffentlich sein. (Im Beispiel oben erhält sie den Standardzugriff private.) Die einschließende Klasse oder die Struktur muss nicht statisch sein.

Von hier: msdn.microsoft.com/d...ibrary/acy3edy3.aspx

Dingo · Beiträge: 64 Erhaltene Danke: 1

Verstehe!^^

Ich sitze gerade an diesem Beispiel hier (endlich die Codefunktion des Forums gefunden^^):

markieren

C#-Quelltext

1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
15:
16:
17:
18:
19:
20:
21:
22:

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;

namespace Lektion2
{
    class Program
    {
        static string ToString(int value)
        {
            return "" + value;
        }
        
        static void Main(string[] args)
        {
            string s = Program.ToString(123456);
            Console.WriteLine(s);
        }
    }
}

Also an dem Beispiel mal, ToString ist eine Methode, die sofort beim Start aufgerufen wird, benötigt dafür ein static.
Den Code an sich versteh ich schon, nur warum ich ein static davor schreiben muss, wird mir immer noch nicht klar.

Es ist doch eigentlich ein normaler Methodenaufruf in der Klasse Program?

Muss man es so sehen, dass eigentlich eine Methode zu einem Objekt gehört und so lange es noch kein Objekt gibt, eigentlich auch keine dazugehörige Methode gestartet werden könnte?

Ralf Jansen · Verfasst: Di 07.03.17 13:08

Ohne static an ToString brauchst du eine Instanz der Klasse Program um die aufzurufen.
Also dann

markieren

C#-Quelltext

1:
2:

Program program = new Program();
program.ToString(123456);

Da aber an der Instanz keine weiteren Informationen hängen die man aus der Instanz holen müßte damit ToString das richtige macht wäre static hier richtig. Denn alles was die ToString Methode braucht um seine Funktion auszuführen bekommt es übergeben. Es besteht also keinen Bedarf für eine Instanz bzw. weitere Instanz der Klasse Program.

Dingo · Beiträge: 64 Erhaltene Danke: 1

Ok und wäre es nicht möglich ToString gleich auszuführen, innerhalb der Main Methode, ohne extra über eine Methode zu gehen? Oder macht man sämtliche Berechnungen und der gleichen über Methoden mit Rückgabewert?

EDIT:

Gut, ich hab noch mal in nem anderen Buch nachgelesen, demnach ist Static ein Feld, sprich also eine Variable oder Methode, die keinem bestimmten Objekt zugehörig ist, sondern einer Klasse angehört, also nach Buch eine Klassenvariable ist...

Noch nicht ganz einleuchtend aber schon klarar...

Würde also bedeuten:
Eine Klassenvariable bekommt einen Wert in der Klasse zugeordnet?
Eine Instanzvariablen bekommt einen Wert im Objekt zugeordnet?

Ralf Jansen · Verfasst: Di 07.03.17 14:52

Zitat:

Würde also bedeuten:
Eine Klassenvariable bekommt einen Wert in der Klasse zugeordnet?
Eine Instanzvariablen bekommt einen Wert im Objekt zugeordnet?

Ja. Es wird möglicherweise klarer wofür man das braucht wenn du bedenkst das es die Klassenvariable nur einmal gibt während du natürlich ganz viele Instanzen der selben Klasse erzeugen kannst und jede Instanz dann eine eigene Instanzveraiable mit ihrem eigene Wert haben kann.

Darum einen Programmeinstiegspunkt brauchst du genau einmal und das auch eindeutig auffindbar darum ist static das Richtige für die Main Methode. Hättest du eine Klasse die eine Person beschreibt, dann wäre ein Feld das den Geburtstag der Person beschreibt besser nicht statisch denn jede Person(jede Instanz der Klasse Person) ist potentiell an einem anderen Tag geboren worden. Würdest du aber zum Beispiel ein Feld an dieser Klasse haben das beschreibt mit welchem Alter diese Person Volljährig wird/wurde dann könntest du überlegen ob dieses Feld nicht statisch sein sollte. Weil diese Info für alle Personen gleich ist.

Dingo · Beiträge: 64 Erhaltene Danke: 1

Könnte man also sagen, dass Klassenvariablen "Globale Variablen" sind, die überall einsetzbar sind und überall den selben Wert besitzen?

	Mitgliederliste
	Gruppen
	Das Team
	Richtlinien
	Synonyme