Wieso wird nicht einfach das GUI vom Betriebssystem übernommen?

[Ekelpack]

proc schrieb:
-------------------------------------------------------
> autor schrieb:
>
> >
> UIManager.setLookAndFeel(UIManager.getSystemLookAn
>
> dFeelClassName());
>
> Was n das, funktionales OO? Sieht ja pervers aus
> diese Javafricklelei.

In jeder anderen Sprache würde es genauso aussehen, vorausgesetzt die Sprache unterstützt LookAndFeels.

[Ekelpack]

DetlevDevel schrieb:
-------------------------------------------------------
> Das Beispiel ist vollkommener Unsinn. Code sollte
> so strukturiert sein, dass in Situationen wie der
> angesprochen »Sum += 1« auf keinen Fall ein
> Property angesprochen wird. Properties machen
> nämlich durchaus Sinn, wenn es sich nicht um
> simple Objecte / Datentypen handelt (wie Ints,
> Floats etc. pp.). Von daher ist es absolut
> unprofessionell zu behaupten, das Properties per
> se vermieden werden sollten.
>

Properties sind einfach nur Augenzucker.
Ob man nun Properties schreibt oder Getter/Setter generieren lässt, macht funktional doch keinen Unterschied.

Man gewöhne sich einfach an die jeweiligen Techniken zu benutzen. C# -> Properties, Java -> Getter/Setter...

Es bleibt zwar immer ein komischer Beigeschmack wenn ich Properties benutzte, denn es sieht auf den ersten Blick immer so aus, als wäre der Member public, aber ich komme auch aus einer der tiefsten Java-Ecken...

[zilti]

blubbiii schrieb:
-------------------------------------------------------
> Anstelle eines eigenen (ich finde) häßlichen.


UIManager.setLookAndFeel(UIManager.getSystemLookAndFeelClassName()); und schon hat der Entwickler das Look and Feel des jeweiligen Systems. Dadurch kann es aber z.B. ohne Layout-Manager das Layout kaputt machen, weil nicht auf allen Systemen alle Controls gleich gross sind.

[bofh_small]

java schrieb:
-------------------------------------------------------
> Hello_World schrieb:
> --------------------------------------------------
> -----
> > Ano schrieb:
>
> --------------------------------------------------
>
> -----
> > Das ist nicht wirklich der
> native OS
> L&F
> sondern ein speziell
> auf das OS
> angepasste Swing
> L&F. Wer
> nativen L&F
> will kommt um
> SWT/JFace
> nicht herum.
> Wenn man keine Ahnung hat,
> einfach mal die Fresse
> halten. Swing
> unterstützt schon lange ein natives
> Look
> & Feel.
>
> Er hat schon recht. Swing vs. SWT ist wie Qt vs.
> wxWidgets.
>
> SWT und wxWidgets verwenden die echten
> Systemwidgets, müssen sich aber dadurch mit einem
> eingeschränkten Set begnügen, während Swing und Qt
> das native Loog & Feel unter Beachtung der
> Themeinformationen des Zielsystems nachmachen,
> wodurch aber auch Widgets möglich sind, die es so
> nicht auf dem Zielsystem gäbe.
>
Warum sollten sich SWT (und wxWidgets) mit einem eingeschränkten Set begnügen müssen? Das Gegenteil ist bei SWT der Fall - Erweiterungen sind möglich und auch noch (relativ) einfach zu machen.

Bei Swing kann man (eigentlich) vieles machen - sofern nicht wieder mal DirectX spinnt und die graf. Oberfläche des OS zerwürfelt - so ala Taskmanager-Prozessliste überzeichnen, usw..

[Antibrumm]

blubbiii schrieb:
-------------------------------------------------------
> Anstelle eines eigenen (ich finde) häßlichen.


SWT ;)

Neuere Entwicklungen gehen eher in die Eclipse RCP Richtung.

[SM]

blafasel schrieb:
-------------------------------------------------------

okay, dann werf ich einfach mal die delphi ide in die runde

[GodsBoss]

> >
> UIManager.setLookAndFeel(UIManager.getSystemLookAn
>
> dFeelClassName());
>
> Was n das, funktionales OO? Sieht ja pervers aus
Ich glaube kaum, dass eine Methode, die "setLookAndFeel" heißt, sonderlich funktional (im Sinne funktionaler Programmierung) ist. ;-)

Reden ist Silber, Schweigen ist Gold, meine Ausführungen sind Platin.

[kontent]

autor schrieb:
-------------------------------------------------------
> blubbiii schrieb:
> --------------------------------------------------
> -----
> > Anstelle eines eigenen (ich finde)
> häßlichen.
>
> UIManager.setLookAndFeel(UIManager.getSystemLookAn
> dFeelClassName());
>

Es sieht dann maximal so (änhlich) aus, aber es wird sich keineswegs auch so verhalten, z.B. im JFileChooser...

[titrat]

Ekelpack schrieb:
...
> Properties sind einfach nur Augenzucker.
> Ob man nun Properties schreibt oder Getter/Setter
> generieren lässt, macht funktional doch keinen
> Unterschied.

Genauso wie Hochsprachen eigentlich nur Augenzucker gegenüber Assembler sind.

> Man gewöhne sich einfach an die jeweiligen
> Techniken zu benutzen. C# -> Properties, Java
> -> Getter/Setter...

Ich mag Augenzucker und verabscheue Klammeritis für einfache Zuweisungen.
In Java sieht eine Zuweisung einfach nicht mehr wie eine Zuweisung aus, sondern versteckt sich in einem Funktionsaufruf (Klammern).

> Es bleibt zwar immer ein komischer Beigeschmack
> wenn ich Properties benutzte, denn es sieht auf
> den ersten Blick immer so aus, als wäre der Member
> public, aber ich komme auch aus einer der tiefsten
> Java-Ecken...

Das hat mit public / protected etc. doch nichts zu tun.

Auto.Color = Color.Red

ist nun mal lesbarer und klarer als
Auto.Color.Set(Color.Red)
Oder geht nur mir das so?
Java ist da sowas von retro...

[MsTroll]

titrat schrieb:
> Ich mag Augenzucker und verabscheue Klammeritis
> für einfache Zuweisungen.
> In Java sieht eine Zuweisung einfach nicht mehr
> wie eine Zuweisung aus, sondern versteckt sich in
> einem Funktionsaufruf (Klammern).
>
> Auto.Color = Color.Red
>
> ist nun mal lesbarer und klarer als
> Auto.Color.Set(Color.Red)
> Oder geht nur mir das so?

Geht nicht nur Dir so, denke mir dasselbe.

[umgekehrt]

titrat schrieb:
-------------------------------------------------------
> In Java sieht eine Zuweisung einfach nicht mehr
> wie eine Zuweisung aus, sondern versteckt sich in
> einem Funktionsaufruf (Klammern).

Umgekehrt wird ein Schuh draus: In C# sieht ein Methodenaufruf nicht mehr wie ein Methodenaufruf aus, sondern versteckt sich hinter einer Zuweisung.

[slawaweis]

titrat schrieb:
-------------------------------------------------------
> Das hat mit public / protected etc. doch nichts zu
> tun.
>
> Auto.Color = Color.Red
>
> ist nun mal lesbarer und klarer als
> Auto.Color.Set(Color.Red)
> Oder geht nur mir das so?
> Java ist da sowas von retro...

in Java wäre es "auto.setColor(Color.RED)". Direkte Zuweisungen von Objekteigenschaften sind böse. Ohne die konkrete Sprache zu kennen, ist in diesem Fall "Auto.Color = Color.Red" auf den ersten Blick nicht klar, ob es eine Zuweisung zu einer Referenz ist oder ob der Inhalt beider Color Objekte zwischeneinender kopiert wird. Dazu kommen ein paar Eigenschaften hinzu, die man beachten sollte. Was ist, wenn Auto.Color nicht initialisiert ist, d.h. gleich null ist? Was ist wenn Auto.Color gar nicht verändert werden darf? Was ist wenn Auto.Color keine null Werte annehmen darf? Was ist wenn Auto.Color nur bestimmte Werte, wie Color.Blue und Color.Black, annehmen darf? Wenn man von Anfang an mit Get/Set Funktionen arbeitet, vermeidet man diese möglichen Fehler. Weiterhin geht es um Selbstdokumentation und da finde ich solche Sachen wie "Auto.setCarBodyColor(CarBodyColor.getColor("Sahara"))" viel angenehmer zu lesen und zu verstehen, als eine Zuweisung. Weiterhin kann in der Set-Funktion der Wert auf Gültigkeit überprüft werden.

Slawa

[Ekelpack]

titrat schrieb:
-------------------------------------------------------
> Das hat mit public / protected etc. doch nichts zu
> tun.

Naja... es sieht so aus, als würde man dem Member direkt etwas zuweisen, was natürlich quatsch wäre, da direkter Zugriff von außen auf die Member eines Objekts ein totales No-Go ist.


> Auto.Color = Color.Red
>
> ist nun mal lesbarer und klarer als
> Auto.Color.Set(Color.Red)
> Oder geht nur mir das so?
> Java ist da sowas von retro...


Auto.Color = Color.Red;

Aus der Syntax wird aber nicht klar, was man da vor sich hat. Das ergibt sich erst aus dem Kontext.

Ich könnte den Ausdruck aber auch genauso gut

A.C = C.R;

schreiben, dann wäre es mit dem Kontext dahin.
Was ist den nun der Member, was ist eine Konstante? Was davon ist eine Klasse und was ist ein Objekt?

Es lässt sich einfach nicht ohne weiteres herausfinden.

In Java erkennt man es sofort.

auto.setColor(Color.RED);

oder eben

a.setC(C.R);

[..:::...]

DetlevDevel schrieb:

> Das Beispiel ist vollkommener Unsinn.

Du hast den Artikel nicht kapiert!