Vererbung

Csharp-programmierer · Verfasst: Do 21.01.16 18:14

Hallo ihr Experten.
Ich habe neulich eine Basis Klasse geschrieben und andere Klassen von dieser Erben lassen. Dies hat mir sehr gefallen, da ich nicht immer ein extra Objekt erzeugen muss, um auf die Felder dieser KLasse zugreifen zu können.
Anhand der Aussagen auf meine letzten Frage habe ich gemerkt, dass das Schlüsselwort static nicht so gut (oder sowas in der Art) ist.
Wenn ich jetzt eine Klasse habe, wo Strings mit Eigenschaften oder auch Methoden sind und ich diese brache, möchte ich nicht immer ein Objekt instanzieren. Da habe ich gleich mal eine Frage: angenommen ich erzeuge in der Laufzeit 50 mal eine Klasse, wirkt sich dies dann negativ auf die Performance aus?

Und meine zweite Frage: ich erstelle mir eine neue Form mit einem Button und ich diesen Button in VS doppelklicke, öffnet sich das Codefenster der Form 2. Wie dieses Codefenster in der Fachsprache heißt, weiß ich nicht. Aber kann ich dieses Codefenster von einer Klasse erben lassen?
Da steht ja schon:

markieren

C#-Quelltext

1:	public class Form2 : Form

Also erbt diese ja von der FORM. Kann ich die aber noch von einer anderen Klasse erben lassen?
Mfg

_________________
"Wer keinen Sinn im Leben sieht, ist nicht nur unglücklich, sondern kaum lebensfähig" - Albert Einstein

Ralf Jansen · Verfasst: Do 21.01.16 18:24

Zitat:

Wenn ich jetzt eine Klasse habe, wo Strings mit Eigenschaften oder auch Methoden sind und ich diese brache, möchte ich nicht immer ein Objekt instanzieren.

Das wäre aber der Normalfall und ist nicht schlimm. Was schlimm ist wenn man die gleiche Klasse 2mal instanziert und glaubt die Daten da drin hätten irgendwas miteinander zu tun. In dem Fall hilft aber auch Vererbung nicht. Wenn man Klassen benutzt egal wie braucht man die richtige Referenz auf die richtige Instanz der Klasse. Entweder Referenzen rumreichen, Ein Singleton implementieren(wenn etwas tatsächlich nur 1mal existieren soll) oder eben im Zweifel auch eine static Klasse. Man muß nur das richtige zum richtigen Zeitpunkt tun

Zitat:

Also erbt diese ja von der FORM. Kann ich die aber noch von einer anderen Klasse erben lassen?

Nein. Mehrfachvererbung hat zuviele Probleme so das man das in .Net erst gar nicht erlaubt.

C# · Verfasst: Do 21.01.16 18:39

Mehrfachvererbung geht nicht (wie Ralf ja schon gesagt hat). Aber wirklich brauchen tut man dieses Feature auch in den wenigsten Fällen. Meistens reichen auch Interfaces. Du kannst von einer Klasse erben und gleichzeitig beliebig viele Interfaces Implementieren:

markieren

C#-Quelltext

1:
2:
3:

class SuperAwesomeClass : AwesomeClass, IAwesome, IClass, ISuper
{
}

AwesomeClass wäre dann deine Basisklasse und alles was mit I anfängt wären dann Interfaces.

_________________
Der längste Typ-Name im .NET-Framework ist: ListViewVirtualItemsSelectionRangeChangedEventHandler

Palladin007 · Verfasst: Do 21.01.16 19:28

Wenn Du unbedingt von mehreren Klassen erben lassen willst, kannst Du dir mit einem kleinen Trick aushelfen:

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:
23:
24:
25:
26:
27:
28:
29:
30:
31:

// Die Basis-Klasse, die schon vorhanden ist
public class MyBaseClass
{
}

// Die zweite Basis-Klasse, die nicht als Basis gesetzt werden kann
// Erstelle für sie ein Interface, was das bietet, was Du braucht.
public class MySecondBaseClass : IMySecondBaseClass
{
    public void DoSomething()
    {
        Console.WriteLine("Did something");
    }
}

public interface IMySecondBaseClass
{
    void DoSomething();
}

// Die Klasse, die eine zweite Basis-Klasse bekommen soll
// Erzeuge eine Instanz der zweiten Basis-Klasse und implementiere das Interface über diese Instanz
public class MyClass : MyBaseClass, IMyInterface
{
    private readonly IMySecondBaseClass _mySecondBaseClass  = new MySecondBaseClass();

    public void DoSomething()
    {
        _mySecondBaseClass.DoSomething();
    }
}

Das wird spätestens dann Schwierigkeiten machen, wenn Vererbung im Spiel sein soll, allerdings habe ich noch nie ein Beispiel gesehen, wo tatsächlich von zwei Klassen Methoden überschrieben werden müssen.
Wenn die Member der zweiten Basis-Klasse nur private sichtbar sein sollen bzw. sind, dann erstelle eine Proxy-Klasse, die von deiner zweiten Basis-Klasse erbt und die protected-Methoden public zur Verfügung stellt. Darüber kannst Du die dann nutzen.

PS wegen dem Stichwort-Singleton:
Sei damit ganz vorsichtig, Singletons können schnell mehr Probleme verursachen, als sie Vorteile bringen.
Um ganz sicher zu gehen, sollte ein Singleton threadsafe sein, aber auch dann ist es gefährlich, besonders wenn sich in dieser Instanz Daten ändern können.
In den aller aller aller meisten Fällen geht es genauso gut, kein Singleton zu verwenden und stattdessen die Instanz an alle relevanten Stellen weiter zu reichen.

Csharp-programmierer · Verfasst: Do 21.01.16 19:47

Vielen Dank für eure hilfreichen Antworten.
Ich habe mir gerade auf YouTube ein Video über Interfaces angesehen, weiß aber nicht recht wozu ich sie brauche. Letzendlich beinhalten die Strukturen, die ich implimentieren muss. Den Sinn dahinter verstehe ich nicht ganz. Also warum wäre es ratsam, wenn ich Interfaces verwende?

Und warum ist es nicht gut, wenn ich zum Beispiel Datenfelder statisch mache? Das wäre ja einfach dann darauf zuzugreifen. Dann könnte ich ja eine Datenklasse erstellen, welche alle Strings / Methoden beinhaltet. Das wäre ja auch einfach.

markieren

C#-Quelltext

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

public static string pFiles(string path)
{
  get
  {
    return Path.Combine(path, "Datei.xml");
  }
}

Beinträchtigt es die Performance, wenn ich zur Programmzeit mehrere Klassen erzeuge / instanziere?

_________________
"Wer keinen Sinn im Leben sieht, ist nicht nur unglücklich, sondern kaum lebensfähig" - Albert Einstein

Ralf Jansen · Verfasst: Do 21.01.16 20:10

Zitat:

Beinträchtigt es die Performance, wenn ich zur Programmzeit mehrere Klassen erzeuge / instanziere?

Näherungsweise Nein. Selbst in einer simplen Anwendung die du bereits geschrieben hast fliegen vermutlich hunderte Instanzen von irgendwelchen Klassen rum. Es ist dir nur nicht bewusst.

Zitat:

Und warum ist es nicht gut, wenn ich zum Beispiel Datenfelder statisch mache?

Dein Beispiel ist völlig harmlos und da ist das ok. Path.Combine ist ja selbst auch ein statische Methode von Path. Bei dem Begriff Datenfeld denke ich aber an andere Sachen. Datenfeld und statisch verträgt sich im allgemeinen eher weniger.

Zitat:

Den Sinn dahinter verstehe ich nicht ganz. Also warum wäre es ratsam, wenn ich Interfaces verwende?

Da können wir nur die schlauen Sprüche wiedergeben die dir auch alle Quellen nennen wenn du nach Interfaces suchst. Letztlich verstehen wird man die erst (die Interfaces und die Sprüche darüber) nach ein paar Übungen. Wenn du in den Übungen mal so Sachen wie abstrakte Klassen, virtuelle Methoden und auch Verewrbung allgemein durch hast (verstanden nicht nur gemacht) hast du das Rüstzeug um den Sinn von Interfaces zu verstehen. Wie so oft wird es aber an kleinen Bespielen schwierig tatsächlich den Sinn zu verstehen und nicht nur deren Verwendung zu üben.

Palladin007 · Verfasst: Do 21.01.16 20:16

Du deutest es schon an: Ein Interface beinhaltet die Struktur
Wenn Du nun mit einem Objekt arbeitest, muss der Typ dieses Objektes zur Compiletime bekannt sein - Die Klasse, eine Basis-Klasse oder eines der Interfaces
Wenn eine Methode als Parameter ein Interface definiert hat, dann kannst Du alles übergeben, was Du willst, solange das Interface definiert wurde. Auf diese Weise kannst Du die Abhängigkeit zwischen Klassen aufheben und Methoden allgemeiner programmieren.
Um ein relativ umfassendes Beispiel anzuschneiden: Ich arbeite gerade an einer Anwendung, die pluginfähig sein soll. Das heißt, andere Leute können ein Plugin entwickeln, das in einen bestimmten Ordner legen und das Programm erkennt das neue Plugin und bindet es ein. Das Problem dabei ist aber: Woher weiß mein Programm, wie es den Einstiegs-Punkt vom Plugin findet und wie es das Plugin ansteuert? Dafür habe ich dann ein Interface, was definiert, was mein Programm braucht, damit es das Plugin nutzen kann.

Prinzipiell spricht nichts gegen statische Member. In .NET hast Du das auch häufig, wie z.B. die Path-Klasse.
Allerdings ist es wichtig, dass statische Komponenten threadsafe sind. Denn es kann immer sein, dass ein anderer Thread mal darauf zugreift. Das hast Du z.B. gerne bei UI-Entwicklung oder bei UnitTests, die parallel ausgeführt werden. Außerdem sollte ein statischer Member nicht von Anderen abhängig sein.
Gerne wird das bei z.B. Settings genutzt oder bei Hilfs-Methoden.

Csharp-programmierer · Verfasst: Do 21.01.16 20:29

Zitat:

Allerdings ist es wichtig, dass statische Komponenten threadsafe sind. Denn es kann immer sein, dass ein anderer Thread mal darauf zugreift. Das hast Du z.B. gerne bei UI-Entwicklung oder bei UnitTests, die parallel ausgeführt werden. Außerdem sollte ein statischer Member nicht von Anderen abhängig sein.

Also wenn ich jetzt einen statischen String (_path) habe, der den Wert zurückgibt, ist es kein Problem? Wie sieht es bei static void aus? Wenn ich aber darauf aufpasse, dass keine falsche Methode an diesen Wert kommt, sollte es doch eigentlich funktionieren?
user profile icon

Ralf Jansen warum sieht es bei den Datenfeldern anders aus?

Zitat:

Näherungsweise Nein. Selbst in einer simplen Anwendung die du bereits geschrieben hast fliegen vermutlich hunderte Instanzen von irgendwelchen Klassen rum. Es ist dir nur nicht bewusst.

Warum mehrere 100? Ich instanziere die Objekte ja nur ein paar mal?

_________________
"Wer keinen Sinn im Leben sieht, ist nicht nur unglücklich, sondern kaum lebensfähig" - Albert Einstein

Ralf Jansen · Verfasst: Do 21.01.16 20:44

Zitat:

Ralf Jansen warum sieht es bei den Datenfeldern anders aus?

Um das richtig zu beantworten muß ich erst wissen was du genau unter Datenfeld verstehst. Fachbegriffe sind eigentlich nur in englisch fix. Die in deutsch übersetzten sind da eher schwammig.

Zitat:

Warum mehrere 100? Ich instanziere die Objekte ja nur ein paar mal?

Und die des Frameworks? Oder wenn du structs verwendest. Wenn du einen Integer an eine Methode übergibst um ihn darin zu ändern hast du zwischenzeitlich mindestens 3 Integer Instanzen verwendest. Voraussichtlich sogar mehr. Bedenke in .Net ist alles ein Objekt und die werden sehr oft auch implizit erzeugt und zerstört. Nicht nur wenn du irgendwas mit new aufrufst um es zu erzeugen.

Csharp-programmierer · Verfasst: Do 21.01.16 20:53

Also in den Datenfeldern handelt es sich um void- Funktionen, die Ordner erstellen und ein Objekt (de)serialisieren. Sie übernehmen also Speicher -oder Ladefunktionen.
Könnten Sie mir vielleicht auch sagen, wann es verboten ist, ein Feld statisch zu machen?

_________________
"Wer keinen Sinn im Leben sieht, ist nicht nur unglücklich, sondern kaum lebensfähig" - Albert Einstein

Ralf Jansen · Verfasst: Do 21.01.16 20:56

Zitat:

Also in den Datenfeldern handelt es sich um void- Funktionen, die Ordner erstellen und ein Objekt (de)serialisieren. Sie übernehmen also Speicher -oder Ladefunktionen.

Sorry. Verstehe ich nicht. Das ist einfach eine Art von Methode die eine spezifische Aufgabe intern ausführt. Wo das jetzt der Zusammenhang zu statisch und und Datenfeld ist sehe ich nicht.

Zitat:

Könnten Sie mir vielleicht auch sagen, wann es verboten ist, ein Feld statisch zu machen?

Es ist nicht verboten. Es ist nur sehr oft nicht das Richtige.

Palladin007 · Verfasst: Do 21.01.16 20:57

Csharp-programmierer hat folgendes geschrieben :

Also wenn ich jetzt einen statischen String (_path) habe, der den Wert zurückgibt, ist es kein Problem? Wie sieht es bei static void aus?

Ein einfacher String ist kein Problem, genauso wenig wie alle Wert-Typen, da sie kopiert werden.
Was ein Wert-Typ ist, kannst Du heraus finden, indem Du in VS Rechtsklick auf den Typ machst und "Gehe zur Definition" klickst. Was Du siehst ist dann keine Klasse (class), sondern eine Struktur (struct).
Void ist ebenfalls kein Problem, da wird ja nichts zurück gegeben.
Es ist einfach nur wichtig, dass eine solche Methode nichts außerhalb ändert.
Auch wenn Du keine Probleme mit mehreren Threads bekommst, kann es sein, dass dann irgendwo etwas statisches verändert wird, was an ganz anderer Stelle einen Fehler verursacht. Jetzt finde mal heraus, wo nun die falschen Daten her kommen. Wenn Du noch mehrere Threads im Spiel hast, wird das erst richtig lustig.
Oder Du hast eine Exception, weil mehrere Threads gleichzeitig auf das selbe Objekt zugreifen wollen.

Um solche Probleme zu vermeiden, solltest Du alles statische einfach lassen, wenn es nicht zwingend notwendig ist.
Du hast dadurch keine großen Nachteile, vermeidest aber bergeweise Probleme.

Csharp-programmierer hat folgendes geschrieben :

Wenn ich aber darauf aufpasse, dass keine falsche Methode an diesen Wert kommt, sollte es doch eigentlich funktionieren?

Das geht natürlich, aber wie kannst Du dir sicher sein, dass Du immer daran denkst?
Irgendwann erweiterst Du dein Programm, vergisst das und hast einen Fehler, der sich viele Stunden kostet und mit wenigen Sekunden hätte vermieden werden können.

Zitat:

Also in den Datenfeldern handelt es sich um void- Funktionen, die Ordner erstellen und ein Objekt (de)serialisieren. Sie übernehmen also Speicher -oder Ladefunktionen.

Da finde ich das Wort "Datenfeld" sehr missverständlich, für mich klingt das eher wie eine Methode.
Was ich unter Datenfelder verstehe, sind Variablen.

(De)Serialisieren ist kein Problem - solange es eben nur das tut: (De)Serialisieren und sonst nichts.

Csharp-programmierer · Verfasst: Do 21.01.16 21:20

Oder ich schreibe mir eine Datenklasse (wo Properties [Strings, Methoden] als Eigenschaft definiert sind) und Instanziere dieses Objekt dann zwischen dem Namespace und der public partial class.

markieren

C#-Quelltext

1:	IO_Daten io_daten = new IO_Daten();

Von diesern Instanz kann ich ja überall zugreifen, oder?
Und was meinst du von dieser Idee?

_________________
"Wer keinen Sinn im Leben sieht, ist nicht nur unglücklich, sondern kaum lebensfähig" - Albert Einstein

C# · Verfasst: Do 21.01.16 21:27

Das wird nicht funktionieren. Du kannst keine globalen Variablen wie in C erstellen. Jede Variable muss innerhalb einer Klasse sein. Wenn du global auf eine Variable zugreifen willst, mache eine statische Klasse:

markieren

C#-Quelltext

1:
2:
3:
4:

public static class Global
{
    public static string DeineVariable;
}

PS: Properties is das englische Wort für Eigenschaften. Als Property zählt jedes Feld, dass die { get; set; } Accessor implementiert. Felder sind einfach nur deine Klassenvariablen.
PPS: Solche "Global" Klassen sollten aber vermieden werden. Die machen oft mehr ärger als sie helfen.

_________________
Der längste Typ-Name im .NET-Framework ist: ListViewVirtualItemsSelectionRangeChangedEventHandler

Ralf Jansen · Verfasst: Do 21.01.16 21:56

Zitat:

PS: Properties is das englische Wort für Eigenschaften

Schönes Beispiel warum man keine deutschen Fachbegriffe verwenden sollte

Die deutsche Übersetzung von Attribute ist auch Eigenschaft. Ein Attribute ist natürlich was völlig anderes als eine Property.

Zitat:

Von diesern Instanz kann ich ja überall zugreifen, oder?
Und was meinst du von dieser Idee?

Ich glaube das Konzept global solltest du versuchen aus deinem Kopf zu streichen. OO-Programmierung dreht sich explizit um die Konzepte von Sichtbarkeiten (access modifier, scope u.s.w.). "Global" versucht genau das auszuschalten. Global heißt das du von überall darauf zugreifen kannst. Wenn alles auf alles zugreifen kann hast du aber exponentielles Komplexitätswachstum. Die Software und ihr Verhalten wird dann schnell unbeherschbar. Du drehst was an Stelle a und hast keine Chance vorherzusagen wo überall was umfällt weil theoretisch alles von dieser Änderung betroffen sein kann. Um große Software beherrschbar zu halten ist es notwendig dafür zu sorgen das nur die Bestandteile miteinander interargieren(interagieren können) die das unbedingt nötig haben. Dann bleibt Software beherrschbar. "Global" ist genau das Gegenteil.

Also anstatt global etwas zu versuchen sollte du erstmal überlegen wo brauch ich das und wie bringe ich das dahin. Am Ende kommt man vielleicht bei etwas aus das "global" nahe kommt. Das sollte aber nichts sein nachdem man strebt.

Csharp-programmierer · Verfasst: Do 21.01.16 22:13

Sorry. Ich wollte das Objekt zwischen public partial class und dem Konstruktor instanzieren. Dann kann ich innerhalb dieser partiellen Klasse auf das Objekt zugreifen.

_________________
"Wer keinen Sinn im Leben sieht, ist nicht nur unglücklich, sondern kaum lebensfähig" - Albert Einstein

Palladin007 · Verfasst: Do 21.01.16 22:25

Das stimmt, das ist dann eine ganz normale Klassen-Variable.
Solange die nicht statisch ist, ist das unbedenklich - allerdings würde ich die private machen oder anstelle der Variable eine Property verwenden.

Aber warum eine partielle Klasse?
Sowas hast Du meist nur dann, wenn automatisch generierter Code im Spiel ist, also z.B. bei WPF, WinForms, oder T4-Templates.

C# · Verfasst: Fr 22.01.16 00:50

Für den Fall dass du es nicht wissen solltest: partial erlaubt dir, eine Klasse in mehrere Dateien aufzuteilen. Du kannst dann in einer Datei z.B. die öffentlichen Sachen schreiben und in der Anderen die internen Funktionen und Variablen. Wie Palladin007 schon gesagt hat, wird generierter Code wie bei WinForms auch in eine extra Datei geschrieben, damit der Code übersichtlicher bleibt und sicherer ist. Das ist der einzige Sinn und Zweck von partial.

@Ralf

Zitat:

Die deutsche Übersetzung von Attribute ist auch Eigenschaft

_________________
Der längste Typ-Name im .NET-Framework ist: ListViewVirtualItemsSelectionRangeChangedEventHandler

Csharp-programmierer · Verfasst: Sa 23.01.16 21:38

Vielen Dank für eure hilfreichen Antworten. Schönes Forum!

Zitat:

Für den Fall dass du es nicht wissen solltest: partial erlaubt dir, eine Klasse in mehrere Dateien aufzuteilen. Du kannst dann in einer Datei z.B. die öffentlichen Sachen schreiben und in der Anderen die internen Funktionen und Variablen. Wie Palladin007 schon gesagt hat, wird generierter Code wie bei WinForms auch in eine extra Datei geschrieben, damit der Code übersichtlicher bleibt und sicherer ist. Das ist der einzige Sinn und Zweck von partial.

Ich weiß (teils zumindest :hair:

). Das ist die Klasse der zugehörigen Form (also z.B. wenn ich auf einer Form einen Button doppelklicke der generierte Code). Ich habe jetzt die wichtigen Datenstings eingekapselt und statisch gemacht. Auf die Methoden greife ich jetzt über Klassenvariablen zu.
Interfaces werde ich versuchen in meinem nächsten Projekt unterzubringen :wink:

Aber vielen Dank für die Hilfe!

_________________
"Wer keinen Sinn im Leben sieht, ist nicht nur unglücklich, sondern kaum lebensfähig" - Albert Einstein

	Mitgliederliste
	Gruppen
	Das Team
	Richtlinien
	Synonyme