Hallo, sollte man beim erstellen der gui. egal ob swing awt oder SWT die einzlnene controls als public oder private definieren. Denn eigentlcih habe ich ja durch anwenden des MVC konzeptes einen controller, welcher zugriff auf die controls benötigt, was bedeuted, wenn ich sie private mache brauch ich eine get... methode, welche wegfallen würde, wenn ich public verwende.
Wie macht ihr das so, wenn ihr ne gui klasse mit vielen textfeldern oder ähnlichem hab?
naja habe halt in meiner anwendung viele felder sowas wie name, vorname , adresse oder für artikel spezielle eigenschaftsfelder also packungsgröße name nr und so weiter und deswegen halt ziemlich viele get methoden und wollte halt mal wissen ob das so üblich ist oder anders gelöst wird
Da ein TextField mehrere Methoden hatund ich es etwas ungluecklich finde, auf diese alle mit Getter und Setter Methoden zuzugreifen, halte ich sie haeufig protected
Soweit muss die Kapselung doch auch nicht gehen: eigentlich reicht es ja, einen Getter für das TextField zu haben (Setter braucht man da normalerweise nicht); die Instanzmethoden des Textfields kann dann doch ruhig an der Instanz aufrufen, die man mit dem Getter bekommt.
M.E. kann man bei GUIs aber auch mit öffentlichen Feldern leben, da hier das öffentliche API ohnehin zwangsläufig ziemlich nahe an der Implementierung liegen muss und man die grundsätzlich sehr wünschenswerte Abstraktionmöglichkeit, die der Zugriff über (Interface-)Methoden bietet, in diesem Fall normalerweise nicht braucht.
Das gilt wohl umso mehr, wenn die GUI-Klassen (z.B. von einem Werkzeug) immer so gestaltet werden, dass eine Klasse immer einen kompletten Dialog beschreibt und es daher bei den GUI-Klassen weder Ableitung noch Aggregation gibt.
Entscheidend sind IMHO auch solche Fragen, wie: Welche Zugriffe benötigt der Controller? Wie abstrakt muß das ganze für zukünftige Änderungen gehalten werden? public ist in jedem Fall ein no-go. Aber auch ein getter muss z.B. im Falle eines TextFields nicht unbedigt angebracht sein. Was macht man denn mit einem TextField? Man setzt den Text, und man liest ihn aus. Wenn man jetzt eine get-Methode macht, hat man so ein Konstrukt
Code:
class GUI
{
private JTextField textField = ...
public JTextField getTextField() { return textField; }
}
und kann von außen dann so darauf zugreifen
Code:
class Main
{
void foo()
{
String text = gui.getTextField().getText();
...
gui.getTextField().setText(newText);
}
Man hat damit aber u.U. schon VIEL mehr Zugriff, als eigentlich erlaubt sein muss (oder sogar sollte). Vielleicht WILL man einer "außenstehenden" Klasse garnicht die Möglichkeit geben, das TextField z.B. zu enablen/disablen, oder seine Bounds abzufragen oder sein PreferredSize zu ändern...
Abgesehen davon ist es schon allein deswegen nicht günstig, weil man die Implementierung preisgibt. Obige Funktionen (lesen/schreiben von Text) könnten ja (später, vielleicht) von einer JTextArea oder einem JLabel oder irgendeiner anderen Textkomponente übernommen werden - und dann geht das große Ändern los.
In so einem Fall könnte IMHO ein Verstecken der Implementierung und eine Reduzierung der Schnittstelle auf das nötigste sinnvoll sein:
Code:
class GUI
{
private JTextField textField = ...
public void setTheText(String text)
{
textField.setText(text);
}
public String getTheText()
{
return textField.getText();
}
}
Aber die genaue Umsetzung hängt eben von den oben genannten Punkten ab. Wenn man "fast alle" Methoden eines TextFields durchreichen müßte, würde das auch keinen Sinn mehr machen. (Aber wann muss man das schon...)
Hier geht es zwar um SWT, aber da GUI und MVC genannt wurden, wollte ich nochmal eine andere Sichtweise darstellen.
Ohne Getter und Setter (die Namenskonventionen folgen) geht in JSF und struts nicht viel, wobei in struts häufig sogar DynaBeans (HashMaps) verwendet werden.
Beides sind MVC Frameworks.
Natürlich macht es den Quellcode etwas größer, ist aber nicht wirklich komplexer.
Ist natürlich alles eine Frage des Kontextes, ich habe keine Erfahrung mit SWT oder AWT.
