Whiz-zarD

Wenn ich mir das Diagramm anschaue, kommt es mir sowieso an dieser Stelle falsch vor. Ich vermute mal, dass get(k) einfach nur die Filiale aus der Liste holen soll aber nach dem Diagramm erhöht die get()-Methode die Gehälter. Also anstatt: public void erhoeheGehaltMitarbeiter(double x) { var i = meineFilialen.Size(); for(var k = 0; k <= i; k++) { var filiale = meineFilialen.get(k); var meineMitarbeiter = filiale.getMeineMitarbeiter(); var z = meineMitarbeiter.Size(); for(var j = 0; j <= z - 1; j++) { // ... } } } steht dort einfach nur: public void erhoeheGehaltMitarbeiter(double x) { var i = meineFilialen.Size(); for(var k = 0; k <= i; k++) { meineFilialen.get(k); } } Und die get()-Methode erhöht dann das Gehalt, was aber nicht klappen kann, da die Methode x gar nicht kennt. get() müsste also einen Rückgabewert zur Zentrale zurückgeben.

Ja, Size() holt die Größe der Liste, um damit die Austrittsbedingung der for-schleife zu definieren. Heutzutage würde man das aber mit einer foreach-Schleife lösen.

Was verstehst du denn dort nicht? Das ist eine Schleife, die über die Fillialen läuft. Innerhalb dieser Schleife gibt es eine weitere Schleife, die alle Mitarbeiter durchläuft und bei allen Mitarbeitern, die nicht Fillialleiter sind, wird das Gehalt erhöht.

Stimmt. Hab die Klassen per Copy/Paste in Notepad++ erstellt. Also ohne IDE.

Es ist halt dafür dar, um für Datentypen unterschiedlicher Art einen Eingangspunkt zu ermöglichen. z.B. einer formatierten Ausgabe von Strings: Console.WriteLine("Hallo {0}, ich bin {1} Jahre alt.", "Welt", 42); // Ausgabe: // Hallo Welt, ich bin 42 Jahre alt. "Welt" ist ein String (Objekt) und 42 ein Integer (Wertetyp). Damit die WriteLine()-Methode mit den unterschiedlichen Datentypen umgehen kann, nimmt sie ein object-Array entgegen (man sieht das Array nicht, wegen dem params-Schlüsselwort). D.h. die 42 wird in ein object konvertiert (boxing). Die Methode nimmt sich dies sogar zum Vorteil, da object die ToString()-Methode besitzt und die 42 kann direkt in ein String umgewandelt werden, da es ja nun ein object ist.

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.

Die abstrakte Klasse hat zwar keine Funktionalität, dennoch bräuchte ich neben dem Interface eine abstrakte Klasse, die die Color-Eigenschaft besitzt. Ohne diese abstrakte Klasse müsste ich weiterhin in den konkreten Klassen (Square und Circle) die Eigenschaft implementieren. Mit der abstrakten Klasse habe die Color-Eigenschaft nur ein mal implementiert und spare somit Code und potenzielle Fehlerquellen.

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.

Und welches ominöse Tool für "Big Data" habt ihr installiert?

Was ist eigentlich genau die Aufgabe?

Das hat doch aber absolut nichts mit Big Data zu tun... Big Data sind unstrukturierte Datenmassen aus unterschiedlichen Quellsystemen. Eine (No)-SQL-Datenbank kann nur eine von vielen Quellsystemen sein. Es kann aber auch die Bilder einer Überwachungskamera ein Quellsystem sein oder die Werte eines Sensors oder Log-Dateien, etc. All diese Daten werden in einem Cluster gespeichert und können dort verknüpft werden.

Wieso will man dafür das Rad neuerfinden? Wenn es nur maximal 10 Benutzer sind, dann kann man auch Confluence kostenlos benutzen.

Wie wäre es einfach mit einer Gruppe in einem der unzähligen Messenger? Wenn einer was schreibt, bekommen dies auch alle mit.

Wann benötigt man dann die komplette Infrastruktur des Unternehmens, um irgendwas vorab zu testen? Für gewöhnlich testet man immer im kleinen Stil und wenn man es für gut empfunden hat, kann man es sich überlegen, dies auch im Unternehmen einzuführen. Niemand würde auf die Idee kommen an produktiven Systemen rumzuschrauben und zu experimentieren, sondern immer in einer kleinen Testumgebungen. Kein Arbeitgeber würde dir eine komplette Kopie der IT-Infrastruktur zum Test zur Verfügung stellen.

Ich würde mal behaupten, dass man privat viel mehr Mittel zur Verfügung hat, als beruflich, da beruflich es um die Wirtschaftlichkeit geht. Da hat man nun mal nicht 4 Tage Zeit, um sich mal ein neues Framework oder eine neuen Webserver anzuschauen. Wenn es ein Problem gibt, dann muss es schnell gelöst werden und nicht schön. Also verwendet man die alten Paradigmen und Techniken weiter, weil die jeder kennt und zur Routine gehören. Da können die Paradigmen und Techniken auch ruhig veraltet und schlecht seien aber so hat man es dann immer gemacht und so versteht es auch jeder. Privat hat man aber die Zeit, mal andere Wege für ein Problem auszuprobieren. Wer sich also privat nicht weiterbildet, wird schnell zu den Entwicklern gehören, die den Anschluss verpasst haben.