redstav

"Durch meine Azubiprojekte,(KOMMA) wie z.B. ...
 
 
...der Bundesagentur für Arbeit (KEIN KOMMA) auf Ihre Stellenausschreibung für..
 
Ich bin selbst keine Guru was es Satzzeichen angeht, aber ich würde dir allgemein empfehlen den Text hinsichtlich dieser nochmal genau durchzugehen.
Kein würde. "Ich freue mich auf die Gelegenheit." Ich will dir keine Worte in den Mund legen. Persönlich finde ich folgende Formulierung, bzw etwas in die Richtung, sehr gut: "Ich freue mich darauf Sie in einem persönlichen Gespräch kennen zu lernen und die Gelegenheit die von Ihnen gewonnenen Eindrücke zu vervollständigen."
Vorschlag zur Inspiration, etwas in die Richtung: und bewerbe mich im folgenden für die von Ihnen ausgeschriebene Stelle als Systemadministrator. 
Ich bin hier allerdings auch immer im Zwiespalt und mir nicht sicher was hier das beste Vorgehen wäre. Aber an sich ist dem Personaler bereits klar dass du dich bewirbst und auch worauf. Siehe Titel. 
 
Abgesehen von Unternehmensphilosophie und gutem Ruf würde ich noch kurz weiter auf das Unternehmen eingehen.
Z.B. was macht den guten Ruf aus? Ist das Unternehmen innovativ, qualitativ in seinen Dienstleistungen/Produkten, dynamisch, erfahren. Welche Qualitäten sprechen dich genau an?
Womit kannst du dich identifizieren und warum würdest du da rein passen bzw. das Ganze ergänzen?
 
P.S. Alles schnell herunter getippt, Angaben ohne Gewähr.

"Durch meine Azubiprojekte,(KOMMA) wie z.B. ...
 
 
...der Bundesagentur für Arbeit (KEIN KOMMA) auf Ihre Stellenausschreibung für..
 
Ich bin selbst keine Guru was es Satzzeichen angeht, aber ich würde dir allgemein empfehlen den Text hinsichtlich dieser nochmal genau durchzugehen.
Kein würde. "Ich freue mich auf die Gelegenheit." Ich will dir keine Worte in den Mund legen. Persönlich finde ich folgende Formulierung, bzw etwas in die Richtung, sehr gut: "Ich freue mich darauf Sie in einem persönlichen Gespräch kennen zu lernen und die Gelegenheit die von Ihnen gewonnenen Eindrücke zu vervollständigen."
Vorschlag zur Inspiration, etwas in die Richtung: und bewerbe mich im folgenden für die von Ihnen ausgeschriebene Stelle als Systemadministrator. 
Ich bin hier allerdings auch immer im Zwiespalt und mir nicht sicher was hier das beste Vorgehen wäre. Aber an sich ist dem Personaler bereits klar dass du dich bewirbst und auch worauf. Siehe Titel. 
 
Abgesehen von Unternehmensphilosophie und gutem Ruf würde ich noch kurz weiter auf das Unternehmen eingehen.
Z.B. was macht den guten Ruf aus? Ist das Unternehmen innovativ, qualitativ in seinen Dienstleistungen/Produkten, dynamisch, erfahren. Welche Qualitäten sprechen dich genau an?
Womit kannst du dich identifizieren und warum würdest du da rein passen bzw. das Ganze ergänzen?
 
P.S. Alles schnell herunter getippt, Angaben ohne Gewähr.

Gegenfrage: Hast du wirklich den Sinn von abstrakten Klassen jetzt verstanden?
Es macht wenig Sinn zurück zu abstrakten Klasse zu casten.
Die abstrakte Klasse definiert Methoden und Propterties die deine SubKlasse haben muss bwz. auf die eine Subklasse zugreifen kann.
Manche Methoden sind abstrakt: Bedeutet die SubKlasse muss eine entsprechende Methode dieses Types und mit dem Namen haben...was diese genau macht, ist erstmal egal.
Du kannst auch abstrakte Properties angeben: Heißt die Klasse gibt nur den Namen, den Typ und Getter/Setter an die eine SubKlasse so implementieren muss.
Beispiel:
public abstract class Car{ // Car enthält die Methode navigate...SubKlassen haben darauf Zugriff public void navigate(){ // do stuff } // Subklassen haben Zugriff auf price, Implementierung nicht möglich, da man die Property schon aus Car bezieht public double Price => 50000; // SubKlassen müssen eine Property Name vom Typ String implementieren public abstract string Name { get; set;} // SubKlassen müssen eine Methode drive implementieren public abstract void drive(); }  

Angenommen du hast ein Interface, welches eine Datenbankanbindung definiert:
public interface IDbCommandExecuter { public void InsertInto(string tableName, object toInsert); } Im Moment hast du eine MySql-Datenbank, sodass du eine Klasse schreibst, welche dieses Interface implementiert und die konkrete Implementierung für die MySql-Datenbank aufweist.
public class MySqlCommandExecuter : IDbCommandExecuter { public void InsertInto(string tableName, object toInsert) { // MySql Implementierung hier. } } Jetzt willst du die Methode benutzen und Objekte in die Datenbank einfügen.
... IDbCommandExecuter exe = new MySqlCommandExecuter(); exe.InsertInto("myTable", myObject1); exe.InsertInto("myTable", myObject2); exe.InsertInto("myTable", myObject3); ... Irgendwann später stellst du jedoch fest, dass MySql nicht mehr optimal ist und du jetzt MariaDB verwenden möchtest.
Du schreibst also eine Klasse, welche dein Interface implementiert und die Implementierung für MariaDB hat:
public class MariaDbCommandExecuter : IDbCommandExecuter { public void InsertInto(string tableName, object toInsert) { // MariaDB Implementierung hier. } } Wenn du jetzt MariaDB hernehmen willst, musst du alles nur an einer Stelle ändern, anstatt an vielen verschiedenen.
... IDbCommandExecuter exe = new MariaDbCommandExecuter(); exe.InsertInto("myTable", myObject1); exe.InsertInto("myTable", myObject2); exe.InsertInto("myTable", myObject3); ... Zusammenfassung:
Da das Interface die Anforderungen definiert, die Klasse jedoch die Implementierung, bist du wenn du ein Interface nutzt von der Implementierung unabhängig. Dies bedeutet, wenn du später die Implementierung ändern willst (MySql -> MariaDB) musst du dies nicht mehr an vielen verschiedenen Stellen machen, sondern nur an einer. Das geht, da du weißt, dass jede Klasse, welche dieses Interface implementiert auch eine Implementierung für diese Methode haben muss.
Das Interface definiert also, was getan werden muss, die Klasse wie es getan werden muss. Und wenn du von außen darauf zugreifst, kann dir das wie ja relativ egal sein.

Das Thema hat absolut nichts mit Boxing und Unboxing zu tun, denn Boxing und Unboxing ist was anderes. Boxing und Unboxing wird verwendet, um Wertetypen (integer, double, ...) in Objekte zu wandeln (boxing) und von Objekten wieder zurück in Wertetypen (unboxing). Beispiel für Boxing:
int i = 123; object o = i; // boxing Beispiel für Unboxing:
o = 123; i = (int)o; // unboxing So etwas wird verwendet, wenn man z.B. eine Liste mit unterschiedlichen Datentypen hat:
var list = new List<object>(); In diese Liste kann dann alles reingeschrieben werden. Sei es z.B. Strings oder Integers.
Das Thema, was @redstav anspricht, ist "Vererbung" und Vererbung ist die Haupteigenschaft der Objektorientierung.
Abstrakte Klassen können nicht instanziert werden. Sie können nur vererbt werden, wie in dem Beispiel. Mit abstrakten Klassen können nämlich Grundgerüste geschaffen werden, die dann mit den Subklassen verfeinert werden können. Das Grundgerüst garantiert uns, dass die Subklassen die Eigenschaften und Methoden der abstrakten Klasse besitzt.
Dein Beispiel finde ich aber nicht so toll, da es die abstrakten Klassen schlecht veranschaulicht. Ich versuche es mal mit einem anderen Beispiel: Angenommen wir wollen geometrische Figuren auf dem Bildschirm malen. Wir haben ein Quadrat und ein Kreis und wollen sie als Klassen abbilden. Beide Figuren sollen später mit einer Farbe ausgefüllt werden und sollen eine Methode besitzen, die dafür sorgt, dass die Figur auf dem Bildschirm gemalt wird. Fangen wir naiv an:
public class Square { public double Width { get; } public Color Color { get; } public Square(double width, Color color) { this.Width = width; this.Color = color; } public void Paint() { // Malt Quadrat auf den Bildschirm } } public class Circle { public double Radius { get; } public Color Color {get; set;} public Square(double radius, Color color) { this.Radius = radius; this.Color = color; } public void Paint() { // Malt Kreis auf den Bildschirm } } Nun haben wir zwei tolle Klassen. Nun kommt die Vererbung ins Spiel: Wir sehen, dass der Aufbau beider Klassen dort recht identisch ist. Also können wir eine Grundgerüst - also eine abstrakte Klasse - bauen:
public abstract class Shape { public Color Color {get; set;} public Square(Color color) { this.Color = color; } public abstract void Paint(); } public class Square : Shape { public double Width { get; } public Square(double width, Color color) : base(color) { this.Width = width; } public override void Paint() { // Malt Quadrat auf den Bildschirm } } public class Circle : Shape { public double Radius { get; } public Circle(double radius, Color color) : base(color) { this.Radius = radius; } public override void Paint() { // Malt Kreis auf den Bildschirm } } Square und Circle besitzen nun durch die Vererbung die Eigenschaften von Shape. Mit der abstrakten Paint()-Methode geben wir dann noch zusätzlich an, dass die Methode zwar in den Subklassen zur Verfügung steht aber die konkrete Implementierung in den Klassen Geschehen muss. So wird dann garantiert, dass alle Klassen, die von Shape erben, auch die Paint()-Methode besitzen. Dies ist jetzt nämlich vom Vorteil, denn wir wollen ja geometrische Figuren auf dem Bildschirm zeichnen. Derjenige, der jetzt dafür sorgt, dass die Figur auf dem Bildschirm gezeichnet wird, muss nämlich nicht wissen, ob es nun ein Quadrat oder Kreis ist, sondern muss nur wissen, dass sie vom Typ Shape sind:
public class Screen { public void Paint(Shape shape) { shape.Paint(); } } Screen screen = new Screen(); Square square = new Square(12.5, Color.RED); Cirlce circle = new Circle(10, Color.BLUE); screen.Paint(square); screen.Paint(circle); Die Paint()-Methode in der Screen-Klasse muss also nicht den konkreten  Datentyp (Square oder Circle) wissen (ansonsten müssen wir jeden Typ eine eigene Methode schreiben), sondern muss nur wissen, dass die Klasse vom Typ Shape sein muss, um die Paint-Methode aufrufen zu können.
In den Klassen Square und Circle erkennt man auch, dass beide zwar vom Typ Shape sind aber beide haben unterschiedliche Eigenschaften. Einmal Width (Square) und Radius (Circle). Das sind Eigenschaften, die zwar die konkreten Klassen kennen aber Shape nicht:
Shape s1 = new Square(10, Color.BLUE); Console.WriteLine(s1.Width); // funktioniert nicht, da wir angebenen haben, dass s1 ein Shape-Objekt ist und Shape Width nicht kennt. Square s2 = s1; Console.WriteLine(s2.Width); // funktioniert, da s1 ja ein Square ist und wir sagen, dass s2 ein Square ist.  

Worum es hier geht ist das sogenannte Boxing und Unboxing.
Beim Boxing wird die Variable eines Types (FtStudent) in einen anderen Typ (von dem er ableitet, hier: Student) (implizit) konvertiert und fortan kannst du mit diesem nur noch so arbeiten wie mit dem Basistyp (Student). Die Variable ist aber trotzdem noch vom ursprünglichen Typ (FtStudent).
FtStudent ft = new FtStudent(); Student boxed = ft; // boxed hat nur die Methoden von Student. Willst du nun wieder die Methoden von FtStudent benutzen musst du die Variable unboxen. Dies geschieht explizit mit einem Cast.
FtStudent unboxed = (FtStudent) boxed; // unboxed enthält die Methoden des FtStudent.
Wenn eine Variable also geboxt wird, wird sie fortan als Basistyp behandelt und hat nur dessen Methoden (und Properties etc.), auch wenn sie in Wirklichkeit immer noch von ursprünglichen Typ ist. Der Compiler lässt allerdings nicht zu, dass du die Methoden des unterliegenden Typen aufrufst, dazu musst du die Variable wieder unboxen.
(Hoffe das macht Sinn - wenn nicht such mal nach 'Boxing and Unboxing').
Wozu man das braucht? Wenn du eine abstrakte Klasse (oder meist ein Interface) definierst, dass die Methodensignaturen hat, welche eine Klasse implementieren musst, kannst du die Methoden, wo die Klasse hergenommen wird, so schreiben, dass sie nur die abstrakte Klasse/Interface erwartet.
Dies bedeutet, dass, wenn du eine andere Implementierung haben willst, du nur noch an wenigen Stellen die Klasse ändern musst, und die Parameter der Methode gar nicht anfassen musst.
// Methode braucht Student public void DoSomething(Student s) { // Do something. } // Im Moment ist deine Implementierung des Studenten FtStudent. Student s = new FtStudent(); DoSomething(s); //Wenn du jetzt die Implementierung ändern willst musst du nur ein Wort austauschen. So schaut dann der neue Code aus. Student s = new PtStudent(); DoSomething(s);  

Inzwischen schreibt man auch nicht mehr:
Square square = new Square(...); sondern:
var square = new Square(...); und überlasst den Kompiler den Rest. Die Angabe, um welchen konkreten Datentypen es sich handelt, ist nur eine doppelte Information, da wir mit new Square(...) schon den Datentyp kennen.