Ein JavaNoob sucht Rat. Ich soll ein kleines Programm mit grafischen Elementen für die Uni schreiben. Nun weiß ich nicht, ob man GUI's besser in eclipse oder in NetBeans erstellen soll. Einerseits ist es in NetBeans viel schneller, einfacher und ich vermute in Unternehmen werden deklarative Oberflächen ebenfalls bevorzugt. Aber der Prof könnte NetBeans evtl. mit dem Argument - für Lehrzwecke ungeignet - beanstanden?!
Also, MEIN Prof hat uns damals mit Netbeans arbeiten lassen (und uns auch am Rande den GUI-Builder gezeigt). Andere Profs an meiner Hochschule haben die Studenten sich erstmal mit dem Texteditor abmühen lassen.
Klick dir mal eine halbwegs größere GUI zusammen und versuche mal, den Code zu überblicken. Der Code funktioniert, aber wehe man faß den an der falschen Stelle an oder will den gar umstrukturieren. Ich persönlich finde das Resultat gräßlich.
Profis wissen in der Regel, was sie tun. Die Codegeneratoren helfen einem dabei eher wenig.
Ich persönlich nutze sowas eher, um Bibliotheken kennen zu lernen. Zu sehen wie es aufgebaut wird, was man für die Initialisierung tun muß, ... solcher Kleinkram halt. Aber dann wird das Programm wieder selbstgestrickt.
Zugegeben, um mal schnell was zusammenzuraffeln ist ein Codegenerator ok. Ich zumindest würde die Teile auch nicht verteufeln.
Warst du schonmal in einer Werkstatt? Aus meiner Erfahrung heraus weiß ich, daß es richtig gute Kfz-Mechaniker gibt. Und das längst nicht jeder Kfz-Mechaniker ein Profi ist.
Aber was hat das damit zu tun, ich sehe den Zusammenhang nicht.
Das Problem dabei ist weniger die Code-Generierung an sich, sondern wie das passiert und wie das verwendet wird.
Die üblichen GUI-Builder generieren halt direkt Java-Code in den Produktiv-Klassen, der danach meist noch angefasst wird. Damit hat man dann alle Nachteile, der Code wird höllisch unwartbar (weil riesiger Blob) und nicht mehr per Hand zu managen, ist aber auch nicht vernünftig automatisiert editierbar und damit nicht weiter-entwickelbar.
Wenn man Code vernünftig generiert, also das Was irgendwo deklarativ stehen hat (zB über Annotationen oder in UI-Fall als XML oä), der generierte Code nicht angefasst wird und neu generierbar bleibt (ua. nicht eingecheckt wird und regelmäßig neu generiert wird, zB jeden Build) und das ganze dann in selbst geschriebenem Code über eine öffentliche Schnittstelle benutzt wird, spricht nicht viel gegens Generieren.
Ja, ist mir auch aufgefallen, dass es eine anschauliche Möglichkeit ist, eine Bibliothek kennenzulernen.
Also wenn ich das richtig verstanden habe, dann eignen sich GUI-Builder insbesondere für kleine Programme, die nicht mit Updates versorgt werden müssen.
Ich persönlich nutze sowas eher, um Bibliotheken kennen zu lernen. Zu sehen wie es aufgebaut wird, was man für die Initialisierung tun muß, ... solcher Kleinkram halt. Aber dann wird das Programm wieder selbstgestrickt.
Also das wäre mir zu viel Arbeit. Ich nutze dafür einfach immer Unit Tests. Dazu gibt es dann entweder eine eigene Unit Test Klasse, die ich am Ende wieder aus dem Repository schmeiße oder ich missbrauche eine Test Klasse, in der das am Ende ehh gehören könnte, sprich: bei den Tests der Komponente, in der ich das zuerst brauche, was ich mir da erarbeiten möchte ....
Extra eine UI, auch wenn zusammen geklickt, scheint mir da zu viel Arbeit und auch bei der Nutzung zu umständlich. (Aber ich möchte nicht ausschließen, dass es eine super Arbeitsweise ist, wenn man das so gewohnt ist! Also bitte nicht als Kritik an der Arbeitsweise sehen sondern nur als meine Sichtweise / Beschreibung meiner Arbeitsweise! In der Physik LK Prüfung habe ich schnell per DGL eine Formel hergeleitet, was mein Lehrer aus allen Wolken hat fallen lassen. "Das sei doch nicht gefordert gewesen." und hatte sich dann Sorgen gemacht, dass da etwas falsch verstanden wurde. Aber ich bin halt gegen auswendig lernen von Dingen, die man sich schnell herleiten kann! Das waren 5 Minuten Schreibarbeit bei einer LK Klausur, die über mehrere Stunden ging.... Also um es kurz noch einmal auf einen Nenner zu bringen: Was Dein richtiger Weg ist, kannst nur Du sagen und das ist mir bewusst und daher soll das keine Kritik sein!)
Also wenn ich das richtig verstanden habe, dann eignen sich GUI-Builder insbesondere für kleine Programme, die nicht mit Updates versorgt werden müssen.
Jein.
Fürs reine Prototyping ist das nutzbar, man muss halt damit leben, der Code auch einfach wieder wegzuschmeißen und ist mit dem generierten auch recht eingeschränkt. Die Wartbarkeit bezieht sich nicket nur auf Updates, sondern die Weiterentwicklung im Laufe der Entwicklung - Morgens probierst du es mit zwei Buttons, Abends dann drei...
Grad bei kleinen Programmen ist man meist sowieso ohne GUI-Builder schneller, einen wirklichen Vorteil hat der auch da nicht.
(Ausgenommen ist da immer der JavaFx-SceneBuilder, da funktioniert das von Grund auf anders)
Man könnte das Lehrpersonal vorher fragen womit gearbeitet werden soll. Ansonsten als Kompromiss: die GUI erstens mittels Netbeans GUI Builder und zweitens zu Fuss (ohne IDE) programmieren, siehe im Openbook
Ich verstehe.
JavaFx-SceneBuilder wäre meine nächste Frage. JavaFx ist ja Oracle's neuste Bibliothek und SceneBuilder ist ja ähnlich wie NetBeans wo man Sachen zusammenklicken kann. Ist das also womit heutzutage in Javabereich vorwiegend gearbeitet wird, sodass man sich das unbedingt aneignen soll oder gibt was anderes?
Gefühlsmäßig würde ich sagen, dass Java auf dem Desktop allgemein nicht mehr so stark verbreitet ist. Früher habe ich öfter Swing-Anwendungen geschrieben, heute ist fast nur noch Web angesagt, da man mit dem Browser einen universellen Client gefunden hat.
JavaFX gilt offiziell als Nachfolger von Swing. Der Ansatz ist schon deswegen anders, weil mit FXML die Möglichkeit einer deklarativen Beschreibung der Benutzeroberfläche besteht. Der Scene Builder ist in erster Linie einfach ein graphischer FXML-Editor.
Man unterscheidet zwischen programmierten und deklarativen Oberflächen:
Programmierte Oberflächen sind solche wo man alle Komponenten mit new erzeugt und mit Layoutmanager anordnet. Deklarative Oberflächen sind in einer externen Ressourcendatei beschrieben. Das Format kann z.B. XML sein. Also wenn man mit Scene Builder arbeitet, wird das Layout in einer externen Datei in XML gespeichert und am Ende eingebunden.
