Whiz-zarD

Wo siehst du ein Where? Das einzige Where, was ich sehe, steckt im Subselect. Das ist aber kein Join... Und selbst dafür braucht man die Aufgabe nicht ... Wie gesagt, interessant wird es erst, wenn das Statement auch ausführbar wäre. Ist es aber nicht. Folglich bekommt er nicht die volle Punktzahl. Frage beantwortet.

Ja, schon klar aber wie gesagt, das SQL-Statement ist nicht mal ausführbar. Da braucht man die Aufgabe nicht, um das zu erkennen. Interessant wird es erst, wenn das Statement ausführbar wäre. Außerdem kennt er die Lösung. Da braucht man ihn nun auch nicht eine Lösung vorschlagen. Den Satz verstehe ich nicht mal. Eine Where-Klausel ist kein Join. Die Where-Klausel wird in einem Subselect verwendet.

Und die Antwort lautet nein, weil das SQL-Statement nicht mal ausführbar ist.

Viel braucht man doch gar nicht verstehen. Das sind halt zwei Tabellen: Artikel und Rechnungsposition und die Tabelle Rechnungsposition ist mit der Tabelle Artikel über die Spalte Art_Id verknüpft. Mehr muss man doch nicht wissen.

Wird dann auch nicht funktionieren, da a.Art_Nummer, a.Art_Bezeichnung, a.Art_Preis, nicht gruppiert sind oder du die Werte nicht mit SUM, COUNT, etc. aggregierst.

Deine Lösung funktioniert nicht, da du kein GROUP BY angegeben hast. SUM und COUNT können nur auf Gruppen ausgeführt werden. Darum wurde in der oberen Lösung jeweils ein Subselect genommen.

Da reicht auch oft der gesunde Menschenverstand. Das ist eine Sache zwischen Kosten- und Nutzen. Kostet eine Software viel aber ist der Nutzen gering, dann rentiert es sich nicht. Solche Aussagen kann man auch ohne BWL-Kenntnisse aufstellen.

Eben. Darum würde ich es auch gar nicht so groß an die Glocke hängen, wie es hier einige tun. Man lernt vielleicht ein bisschen, was der Unterschied zwischen Haben und Soll ist und wie man eine Gewinn- und Verlustrechnung aufstellt aber das ist mehr im Stil eines kleinen Crashkurses und ist nur ein Bruchteil davon, was ein Kaufmann lernt. Dies an die große Glocke zu hängen, weil der Fachinformatiker seinen Ursprung beim Datenverarbeitungskaufmann hat, ist aus meiner Sicht ein wenig hochtrabend. Im Alltag wird man auch nicht viel damit in Kontakt kommen. Für eine Kostenaufstellung reicht auch der gesunde Menschenverstand. Außerdem wurde der Beruf Datenverarbeitungskaufmann 1997 in mehrere Berufe unterteilt. Es standen die Berufe Informatikkaufmann, IT-Systemkaufmann, Fachinformatiker und IT-Systemelektroniker. Der Fachinformatiker war also nicht als Kaufmann gedacht, sondern als praktizierender Facharbeiter. Vermutlich sind aber hier wohl einige zu jung und haben die damalige Dotcom-Blase nicht mitbekommen. Die neuen Berufe wurden nämlich damals zur Anfangszeit der Boom-Phase ins Leben gerufen.

Er fragte aber ob, A LEFT OUTER JOIN B nicht das selbe ist, wie B RIGHT OUTER JOIN A und ja, das ist das selbe. In beiden Fällen ist die Grundmenge A. Darum versuche ich immer als erstes die Grundmenge zu schreiben, bevor ich die Menge mit einem LEFT OUTER JOIN filtere. Das lässt sich semantisch besser lesen. Aber die Frage, ob LEFT OUTER JOIN nicht das selbe ist, wie RIGHT OUTER JOIN muss mit einem Nein beantwortet werden. Es kommt hier auf die Reihenfolge an, wie die Mengen zueinander stehen.

Wenn ich mal einen Knoten im Kopf habe, dann nehme ich mir immer dieses Bild als Hilfe: Das Zeigt, welche Menge man bei welchem Join bekommt. Ein Right Join benutzt man eigentlich auch recht selten. Am häufigsten sind die Inner und Left Joins. Ich selber entwickle ja auch seit fünf Jahren Stored Procedures mit PL/SQL (Eine Sprache von Oracle) und kann mich nicht daran erinnern, jemals ein Right Join gemacht zu haben. Ich versuche es immer mit einem Left Join abzubilden, weil es dann leichter zu verstehen ist. Man bildet eine Grundmenge und schränkt diese Menge mit einem Left oder Inner Join ein.

Das ist gestern nur ein bisschen doof gelaufen. Eigentlich wollte ich was schreiben, klickte aber ausversehen auf den Antworten Button und kam nicht mehr dazu, den Beitrag zu erweitern. Deswegen habe ich ihn erst mal gelöscht. Ich habe mir gestern diesen Podcast angehört und frage mich, wieso man sich bei Programmieraufgaben so schwer tut? Zwei verschachtelte Schleifen sollte eigentlich jeder Prüfling hinbekommen. Das hat man in der Firma mit Sicherheit schon tausend Mal programmiert. Das, was ich hier aber sehe, ist, dass man sich in technischen Hilfsmitteln verstrickt. Anstatt das eigentliche Problem zu lösen, erzeugt man immer weitere Probleme. Als Beispiel nehme ich die o.g. Zählung der Vorkommnisse einer IP-Adresse. Selbst in Pseudocode wäre dies weniger als 10 Zeilen: Anzahl := 0 Durchlaufe alle Zeilen Zerlege Zeile in Abschnitte bei Zeichen '|' Durchlaufe alle Abschnitte IP-Adresse := Abschnitt Wenn IP-Adresse == gesuchte IP-Adresse Dann Anzahl + 1 Gebe Anzahl zurück Wie das denn hinterher in den jeweiligen Sprachen umgesetzt wird, ist doch eine andere Sache. Man erkennt aber in den wenigen Zeilen, was der Algorithmus machen soll. Wenn man aber anfängt technische Hilfskonstrukte aufzubauen, wie z.B. Zählervariablen, weil man schon im Pseudocode definiert, dass man auf das Array indexiert zugreift, ist es auch kein Wunder, warum es so schwer wird. Wie gesagt, in C# mit Linq lässt sich die komplette Aufgabe in nur einer Zeile Code lösen. Wie heißt es so schön? "In der Kürze liegt die Würze". Und genau das verstehe ich halt irgendwie nicht. Es wird halt alles so geschluckt, wie es kommt und keiner stellt die Prüfungsmethoden der IHK in Frage. Die Azubis lernen veralteten Kram, die sie nach der Abschlussprüfung gleich wieder vergessen können, verschenken lieber 25 Punkte und die Prüfer sind mit der Programmieraufgabe überfordert. Das hilft doch keinen weiter. Es ist doch für jeden von Interesse, dass hier was geändert wird. Man muss sich doch an den Kopf fassen, wenn Anwendungsentwickler ihre eigentliche Paradedisziplin in der Abschlussprüfung auslassen.

gelöscht

Leider habe ich kein Überblick, wie die Fragen im Allgemeinen gestellt wird. Vielleicht irre ich mich da auch. Meine Zeit als Azubi liegt auch ein bisschen zurück und ich hab damals nur eine Ausbildung zum Mechatroniker gemacht aber in meiner Abschlussarbeit kam eine Aufgabe zur SPS-Programmierung vor und wenn ich mich noch recht erinnere ging es um eine Programmierung einer Maschine, die Kugeln nach ihrer Farbe sortieren soll. Zumindest fand ich damals die Aufgabe sehr einfach. Auch in meiner Ausbildung aus Assistent für Medieninformatik kamen Programmier-Klausuren vor, wo man für einen Algorithmus 20 Minuten Zeit hatte. Da ging es u.a. darum, zu prüfen, ob ein String ein Palindrom ist, mit der Berücksichtigung, dass Groß- und Kleinschreibung und Satzzeichen ignoriert werden sollen etc. Auch das war machbar. Die IHK wird ja keine unmögliche Aufgabe in die Abschlussprüfung packen. Außerdem wird man ja ein paar Ideen haben, wie man mit der Aufgabe anfangen kann. Das gibt ja schon ein paar Punkte. Wenn ich mir dann auch noch diesen Thread anschaue, wo offenbar eine Aufgabe aus einer Abschlussprüfung stammt, ist das jetzt nun auch kein Hexenwerk. Laut Struktogramm sind das lediglich nur zwei verschaltete Schleifen. Ich hab mir das Struktogramm genommen und mal in C# umgesetzt. Wenn ich das Struktogramm jetzt richtig verstanden habe (ich verstehe nicht, warum die Anzahl der IP-Adressen pro Zeile auf 4 beschränkt wird), war das jetzt eine Zeile Code. int count = zeilen.SelectMany(zeile => zeile.Split('|')).Count(ipAddress => ipAddress == searchIpAddress);

Man bekommt aber Teilpunkte für die Aufgaben und für einen Anwendungsentwickler sind das leichtverdiente Punkte. Diese Aufgaben grundsätzlich auszulassen halte ich für falsch. Dann schreibe bitte den Text auch so. Du suggierierst den Leser, dass Pseudocode auch im Alltag verwendet wird: Und das ist schlichtweg falsch. Wer etwas "runterprogrammiert" hat schon automatisch einen schlechten Programmierstil. Man muss hier auch bedenken, dass man es bei der Abschlussprüfung nicht mit absoluten Neuanfängern zu tun hat, sondern eigentlich schon ausgebildete Fachkräfte, die nur noch in der Abschlussprüfung ihr Können unter Beweis stellen sollen. Wir haben es hier also nicht mit Hobby-Hackern zu tun, die man mit Samthandschuhen anfassen muss, sondern mit Menschen, die damit ihr tägliches Brot verdienen wollen und da verlange ich schon eine gewisse Professionalität. Sicherlich, mein Code sah direkt nach der Ausbildung auch nicht so aus, wie jetzt, denn das kommt erst mit zunehmender Erfahrung aber den Prüflingen was falsches zu vermitteln, halte ich für kontraproduktiv. Man kann den Prüflingen ja darauf hinweisen, dass die IHK eine veraltete Vorstellung hat und dass man deswegen lieber auf Pseudocode setzen sollte, weil es schneller, nicht standardisiert und sprachenunabhängig ist aber denen damit eine zeitgemäße Entwicklung vorzugaukeln und sie so zubehandeln als seinen sie noch im ersten Lehrjahr halte nicht für richtig. Man sollte schon das Kind beim Namen nennen und auch die Dinge kritisch betrachten und sie nicht einfach hinnehmen. Nur so kann man auch was erreichen.

Ich will dir nicht zu nahe treten aber ernsthaft? O_o Du machst eine dreijährige Ausbildung zum Anwendungsentwickler und gerade deine Paradedisziplin in der Abschlussprüfung würdest du lieber auslassen wollen? Darf ich dann fragen, was du in den letzten drei Jahren gemacht hast? Wenn, dann würde ich auch Pseudocode schreiben, denn Diagramme verbrauchen zu viel Zeit. In Prüfungen, wo man nicht vor der Maschine sitzt, macht Pseudocode Sinn, weil der Code eh nicht wirklich lang wird, aber ich würde diesem Code keine allzu große Aufmerksamkeit schenken, denn Pseudocode ist entgegen der Behauptung in diesem Text: ebenfalls nicht mehr zeitgemäß und im alltäglichen Berufsleben wird man auch nie mehr Pseudocode schreiben. Als Softwareentwickler sitzt man dann eh vor seinem Gerät und kann seinen Code zum Ausprobieren in die Maschine hacken. Pseudocode auf Papier ist dann nicht mehr erforderlich. Pseudocode ist auch keine brauchbare Dokumentation, denn erstens interessiert sich der Aufrufer nicht für die dahinterstehende Implementierung und zweitens sollte ein Code schon so sauber geschrieben werden, sodass keine weitere Dokumentation für die Beschreibung der Implementierung des Algorithmus benötigt wird. Wozu sollte so eine Dokumentation auch nützlich sein? Ein Softwareentwickler kann auch den Quellcode lesen. Da braucht man kein Pseudocode. Bestimmte Konstrukte, wie z.B. for-schleifen, verwendet man auch im Alltag nur noch sehr selten. Auch Arrays kommen nicht mehr so häufig explizit zum Einsatz, denn zu über 90% wird man nur durch die Elemente iterieren, da bieten sich dann eher Iteratoren an, anstatt eine Indexierungsvariable, um besseren und lesbaren Code zu schreiben. Ich selber kann mich auch gar nicht mehr daran erinnern, wann ich zuletzt eine for-Schleife geschrieben habe. Pseudocode sorgt auch, meiner Meinung nach, für einen schlechten Programmierstil, da man alles in Spaghetticode runterschreibt und wenn man doch den Pseudocode in Methoden aufteilt, dann wird es auch schnell komplexer und dann hätte man den Code auch selbst in die Maschine hacken können. Das selbe gilt auch für die im Text erwähnten Switch-Anweisungen. Switch-Anweisungen an falschen stellen erhöhen deutlich die zyklomatische Komplexität. Man sollte sie also mit Vorsicht genießen oder sie sogar eher vermeiden. Switch-Anweisungen verwende ich eigentlich eher nur noch für Factory-Methoden. Aber auch nur dann, wenn ich weiß, dass diese Methode nie mehr angefasst wird und es auch nicht zu viele Abzweigungen gibt. Wenn eine Firma sogar TDD (test-driven development) anwendet, wird man eh im ersten Schritt erst eine geeignete Schnittstelle ausdenken und gegen diese Schnittstelle ein Test schreiben und erst dann über eine konkrete Implementierung nachdenken.

Ich würde es auch erst mal lassen. Du hast einen Rahmen vorgegeben, womit der Arbeitgeber spielen kann und der Arbeitgeber liegt ja in deinem vorgegebenen Rahmen. Anders wäre, hättest du eine konkrete Zahl genannt. Ich würde es dann nach der Probezeit noch noch mal ansprechen. In vielen Firmen findet auch ein jährliches Gespräch statt, wo das Gehalt neu verhandelt werden kann.

Die Frage ist, was willst du lernen? Die Java-Basics? Oder bist du schon über die Basics hinaus? Dann muss du schon spezieller Suchen. Du wirst kein Kurs finden, der für jeden Anwendungsfall eine Lösung parat hat. Ein Kurs über die Basics wird kaum ein Wort über die SOLID-Prinzipien verlieren. Bei Kursen kann ich Pluralsight.com empfehlen, wenn du der englischen Sprache mächtig bist. Ansonsten kannst du beim deutschen Konkurrent Video2Brain nachschauen, wobei Pluralsight ein deutlich größeres Angebot hat. Beide sind aber kostenpflichtig.

Es würde mich doch sehr arg wundern, wenn die Ausbildungen beider Berufe sich nur marginal unterscheiden würden. Ein Anwendungsentwickler ist kein Systemintegrator und umgekehrt. Sie haben zwar Überschneidungen aber im Ganzen sind sie sehr unterschiedlich.

Ist das untere Bild die Lösung? Wenn ja, denn ist die Lösung äußerst schlecht. Die Namen der Variablen ist schlecht gewählt und auch sonst arbeitet man heutzutage kaum noch mit for-Schleifen. Man verwendet heute überwiegend die foreach-Schleife, da diese Schleife uns direkt das Objekt gibt, das wir als nächstes betrachten wollen. Man muss also nicht per Indexierung das jeweilige Objekt aus einer Liste/Array rausholen. Es überrascht mich auch, dass heutzutage noch so viel Wert auf Pseudocode und Struktogramme gelegt wird. In der Praxis wird man kaum bis gar nicht damit in Berührung kommen. Zumindest nicht auf der Ebene der Programmierung. Zum eigentlichen Problem: Dein Code stellt nicht das Struktogramm dar. Beispiel: if (iAnzahlITZ = 0){ for (Wiederhole iZeile =0; mach das so lange bis du die Arraylaenge erreicht hast; erhöhe Schrittweise um +1) } wenn iAnzahlITZ gleich 0 ist, durchläufst du einfach nur alle Zeilen aber du machst dort nichts. Das Durchlaufen der Zeilen soll aber auch immer stattfinden und nicht, wenn iAnzahlITZ 0 ist. Auch hast du keine Methode definiert. Du hast also wohl nicht nur Probleme Java-Code zu schreiben, sondern auch Probleme Struktogramme zu lesen. Ich habe mal den Code der ersten beiden for-Schleifen geschrieben. Vielleicht fällt dir dein Fehler selbst auf: public class Pseudo { private string sVergleich_IP = ""; private char cZeichen; private int iIPAnzahl = 0; private int iAnzahlITZ; public int AnzahlIPs(string sSuch_IP, string[] sTextTeilen) { // Wiederhole von iZeile = 0; solange iZeile < Arraylänge von sTextTeilen; Schrittweise 1 for (int iZeile = 0; iZeile < sTextTeilen.length(); iZeile++) { iAnzahlITZ = 0; // Wiederhole von iPosition = 0; solange iPosition < Arraylänge von sTextTeilen[iZeile]; Schrittweise 1 for (int iPosition = 0; iPosition < sTextTeilen[iZeile].length(); iPosition++) { ... } } } } Wie du vielleicht erkennen kannst, sind die for-Schleifen ineinander verschachtelt. Du hast sie aber nur untereinander geschrieben aber wie gesagt, das Struktogramm aber echt grausam. So sollte man echt keinen Code schreiben. Ich komme zwar aus Schleswig-Holstein, aber ich denke auch nicht, dass Pseudocode anerkannt wird, wenn es nicht explizit erfordert wird. Ich hab zwar damals nur eine Ausbildung zum Mechatroniker gemacht aber selbst da haben wir SPS-Programmierung gemacht und die Aufgaben sollten in der Sprache erledigt werden, wie @afo schon sagt, die wir in der Berufsschule gelernt haben.

Man sollte zwar Anfängern nicht gleich solche Schinken zum Fraß vorwerfen aber ich finde, man sollte schon so früh wie möglich, sich mit solchen Themen beschäftigen. Wir haben bei uns gerade einen Schülerpraktikanten, den wir eine Aufgabe zum Lernen gegeben haben, da unsere Anwendung für einen Anfänger zu komplex und wohl auch zu langweilig sein wird. Ja, er schreibt Spaghetticode. Für den Anfang kann er das auch ruhig. Dennoch haben wir bemerkt, dass er sich ein bisschen schwer tut, durch sein Code zu navigieren und sein Code zu debuggen, weil er selber nicht so ganz weiß, was sein Code macht und wo eine Aktion ausgeführt wird. Wir haben ihn ein paar Tipps gegeben, wie er die Klassen und Methoden gestalten kann und haben ihn geholfen, sein Code zu strukturieren. Danach fand er sich im Code auch wesentlich besser zurecht. Das Problem kenne ich auch aus eigener Erfahrung, als ich zur Schulzeit nur hobbymäßig programmierte. Bei jedem Projekt verlor ich schnell die Lust, weil ich irgendwann nicht mehr durch meinen Code durchgestiegen bin und auch sehr fehleranfällig war, weil ich einfach nicht die Strategien kannte, wie man seinen Code strukturiert. Ich hoffe, dass deine "If-Schleifen" und "For-While-Unterscheidungen" irgendwie lustig gemeint sein sollte. Ansonsten: http://www.if-schleife.de/ ...

Natürlich kann man die Welt auch nur mit einer Klasse retten aber das ist nicht Sinn und Zweck der Objektorientierung. Bei der Objektorientierung kann man eigentlich jedes simple Problem in mehrere Klassen aufteilen. Wenn man es dann dogmatisch betrachtet, kann man es so weit führen, dass in jeder Klasse nur noch eine Methode steckt. Wenn du das Single-Responsibility-Prinzip verstanden und dir auch verinnerlicht hast, bekommst du auch ein Gespür dafür, wie Klassen und Methoden gestaltet werden müssen. Ein Beispiel: Wir wollen eine Klasse schreiben, die eine E-Mail verschicken soll. Das Interface sieht im ersten naiven Schritt so aus: public interface IEMailSender { public string From { get; set; } public string To { get; set; public string Title { get; set; } public string Content { get; set; } public void Send(); } Wir sehen hier, dass From und To vom Typ String sind. Da kann alles mögliche drinnen stehen. Wir müssen also prüfen, ob es valide E-Mail-Adressen sind. Der naive Gedanke wäre nun, eine private Methode in der Implementierung des Interfaces zu basteln: public class EMailSender : IEMailSender { public string From { get; set; } public string To { get; set; public string Title { get; set; } public string Content { get; set; } public void Send() { if(this.IsVaildEMailAddress(this.From) && this.IsVaildEMailAddress(this.To)) { // TODO: Versende E-Mail } } private bool IsVaildEMailAddress(string potentialEMailAddress) { // TODO: Überprüfung auf korrekte Adresse } } Aber ist die Validierung der E-Mail-Adresse wirklich die Aufgabe des E-Mail-Versenders? Nein. Muss der Versender den Titel und den Inhalt explizit wissen? Nein. Der E-Mail-Versender soll nur die E-Mail versenden. Mehr nicht. Also sollte man anfangen, die einzelnen Bestandteile zu zerlegen. Was brauchen wir denn alles für den E-Mail-Versand? Wir brauchen eine E-Mail und ein Versender. Die E-Mail ist noch mal unterteilt in eine Sender- und Empfänger-Adresse, Titel und Inhalt. Also: public interface IEMailSender { void Send(EMail eMail); } public class EMailSender : IEMailSender { public void Send(EMail email) { if(email == null) throw new NullReferenceException(); // TODO: Versende E-Mail } } public class EMail { public EMailAddress From { get; set; } public EMailAddesss To { get; set; } public string Title { get; set; } public string Content { get; set; } } public class EMailAddress { public string Address { get; } public EMailAddress(string address) { if(!this.IsValidFormat(address)) throw new FormatException(); this.Address = address; } private bool IsValidFormat(string potentialEMailAddress) { // TODO: Überprüfung auf korrekte Adresse } } Der E-Mail-Sender muss dann nur noch prüfen, ob er auch eine E-Mail zum Versenden bekommen hat. Die Validierung, ob die E-Mail-Adressen korrekt sind, passiert dann schon beim Setzen der E-Mail-Adresse. Der Aufruf erfolgt dann so: EMail email = new EMail { From = new EMailAddress("foo@bar.de"), To = new EMailAddress("bar@foo.de"), Title = "Hallo Welt", Content = "Ist das Wetter nicht schön?" } IEMailSender sender = new EMailSender(); sender.Send(email); Mit Dependency Injection könnte man dann noch den EMailSender in die Klasse reinreichen, wo er verwendet wird. Dann würde man innerhalb der Klasse nur noch gegen das Interface arbeiten und wäre von der konkreten Implementierung unabhängig. Wie du siehst, haben wir bei diesem Beispiel schon drei Klassen und ein Interface geschrieben. Ich kenne jetzt eure Beispiele in der Schule nicht aber wenn ich schon sowas lese, wie "Sitzplatz-Reservierungs-Programm", dann kann ich mir nicht vorstellen, dass man euch wirklich die Objektorientierung richtig erklärt, wenn ihr dafür nur eine Klasse geschrieben habt. Alleine wenn ihr schon eine GUI (WinForms oder WPF) verwendet habt, dann fallen mir schon spontan drei Klassen ein, die man dafür bräuchte, um das Problem gekapselt abzubilden. Das Stichwort wäre hier MVC (Model-View-Controller) bzw. MVP (Model-View-Presenter).

Hallo, als FISI wird man ja nur sehr wenig programmieren. Du wirst eher damit zu tun haben, Netzwerke zu administrieren. Also würde es sich eher lohnen, sich mit Kommandozeileninterpreter wie z.B. Powershell (Windows) oder Bash (Linux) auseinanderzusetzen, anstatt eine Programmiersprache (C, C++, Java, C#, etc.) zu lernen. Wenn du aber unbedingt auch noch eine Programmiersprache lernen möchtest und du schon mit C und C++ Erfahrung hast, kannst du dir auch mal Go anschauen. Das ist eine Programmiersprache von Google, die quasi als Nachfolger von C gilt und auch von der Person entwickelt wird, der damals mitunter C entwickelt hat.

Ja, stimmt. Da hatte ich wohl gerade ein Knoten im Gehirn. ^^"

Das, was du definieren willst, ist eine sog: 1:n (One-to-many)-Beziehung. D.h. ein Kunde besitzt mehrere Module. Hierfür brauchst du eine dritte Tabelle, die die beiden verbindet.

Das ist leider so ein Problem. Oft lernt man nur triviale Dinge und diese werden dann wegen der Einfachheit nicht richtig erklärt bzw. nicht genug durchleuchtet. Es werden dann Risiken und Probleme ausgeklammert und gar nicht behandelt, weil das einen Anfänger verwirrt. Ich finde auch, ein Anfänger sollte nicht mit einer Benutzeroberfläche anfangen, sondern mit einem Kommandozeilen-Tool, um überhaupt erst mal ein Gefühl für die Sprache zu entwickeln. Eine Kommandozeile ist auch nicht so komplex wie eine Benutzeroberfläche. Microsoft hat es zwar nett gemeint, mit dem WinForms-Designer aber leider hat sich herausgestellt, dass die einfache Herangehensweise (Button in die Form ziehen, Doppelklick auf den Button und ausprogrammieren) zu vielen Problemen führt. Nicht umsonst haben sich Schlaue Köpfe überlegt, wie man die Entwicklung von Oberflächen von der Geschäftlogik entkoppelt und Dinge wie MVC (Model-View-Controller), MVP (Model-View-Presenter) oder MVVM (Model-View-ViewModel) entworfen. Ich sage ja nicht, dass ein Anfänger sich nun streng daran halten sollte, denn diese Techniken sind nicht unbedingt leicht zu verstehen aber ich finde, es ist schon wichtig, dass ein Anfänger die Teilaufgaben in seinem Projekt erkennt und die Teilaufgaben in Klassen und Methoden gliedert. Buttons rumspringen lassen, halte ich auch nicht für zielführend. Ein Anfänger sollte schon sinnvollere Aufgaben lösen. In meinem Studium haben wir u.a. anfangen die Fibonacci-Reihenfolge zu berechnen oder ein Sudoku-Löser zu entwickeln.