"Partial" classen

[MrDude]

Hallo alle zusammen,

ich bin ein Quereinsteiger von C# und bin mir von dort gewohnt, dass man eine Class als "Partial" definieren kann, damit man sie in zwei Dateien aufteilen kann. Dieser Vorgang macht das Arbeiten mit Fenstern ein wenig einfacher da man dort die Class so teilen kann:

Form1.Designer.cs
Hier steht alles was mit dem Aussehen von einem Fenster zu tun hat (Grösse, Farbe, Gewicht :autsch: )

Form1.cs
Hier kommt der Code rein, den man schreibt was passieren soll, wenn man auf einen Button drückt.

Dabei wird die Designer-class so definiert:

partial class Form1 { [...] }

und die Code-class so:

public partial class Form1 : Form { [...] }

Wenn man nun in der Code-class z.B. den Text auf einem Button ändern will kann man einfach

Button1.Text = "Neuer Text";

schreiben und muss nicht etwa

Form1.Designer.Button1.Text = "Neuer Text";

schreiben, da die Klassen ja durch das "Partial" miteinander verbunden sind...

Da dies sehr angenehm und ordentlich ist, also den Code vom Design zu trennen, möchte ich das natürlich auch in Java haben, falls es so etwas gibt.
Im Internet habe ich nichts darüber gefunden, aber vielleicht hat ja hier Jemand eine Lösung wie man es machen könnte...

Viele Grüße,
Daniel

 

[FelixB]

ich persönlich habe von sowas noch nie gehört...

 

[Guest]

Ich kenne das aus C# aber in Java gibt es diese Möglichkeit nicht.

 

[The_S]

Ich hab kA von C# und auch nicht was du genau mit "Code" und "Design" meinst, aber grundsätzlich sollten grafische Elemente sowieso von der Logik getrennt werden. Nennt sich MVC-Prinzip

 

[MrDude]

Ich hab kA von C# und auch nicht was du genau mit "Code" und "Design" meinst

Mit Code und Design meine ich den Code der sagt was passiert wenn man auf Button1 klickt bzw. alles das was mit dem Design eines Forms zu tun hat (wie gross es ist, welche Farbe es hat, wo ein wie grosser Button sitzt etc...)

aber grundsätzlich sollten grafische Elemente sowieso von der Logik getrennt werden. Nennt sich MVC-Prinzip

Da schlag ich mal eben nach :### aber wie meinst du da das "von der Logik her trennen"? Ich meine jetzt eher, dass man eben alles was mit dem Design des Forms zu tun hat in eine Datei und alles was mit der Funktionsweise eines Forms zu tun hat in eine Andere.

Bei C# kann man eben so ganz einfach eine Klasse auf zwei Dateien verteilen. Ich habe darüber ein wenig in meinem Blog geschrieben: blog.zipor.eu

 

[The_S]

Da ich immernoch kA von C# habe ( ), mutmaße ich jetzt einfach mal, dass das, was du in C# in eine Klasse packst, aber auf mehrere Dateien verteilst, in Java sowieso in mehrere Klassen und somit mehrere Dateien gehört.

 

[Wildcard]

Da schlag ich mal eben nach :### aber wie meinst du da das "von der Logik her trennen"? Ich meine jetzt eher, dass man eben alles was mit dem Design des Forms zu tun hat in eine Datei und alles was mit der Funktionsweise eines Forms zu tun hat in eine Andere.

Bei C# kann man eben so ganz einfach eine Klasse auf zwei Dateien verteilen. Ich habe darüber ein wenig in meinem Blog geschrieben: blog.zipor.eu

Die Darstellung und das Verhalten sind 2 völlig unterschiedliche Aufgaben.
Demzufolge ist es auch sinnvoll hier mit echt verschiedenen Klassen zu arbeiten, einer View und einer Controler Ebene die somit 2 Teile des MVC Paradigmas stellen.

 

[The_S]

Und wie ich sehe, stimmt mir Wildcard zu 8)

 

[Guest]

Partial dient eigentlich nicht dazu 2 Klassen zu "verbinden" sondern lediglich eine Klasse auf mehrere Dateien aufzuteilen. Damit der Compiler weis, das der Quellcode einer Datei nur einen Teil einer Klasse darstellt muss diese partial deklariert werden. Die endgültige Klasse wird aus diesen Teilen zusammengesetzt.

Wie gesagt gibt es aber solch ein Konstrukt in Java nicht.

 

[Leroy42]

... und wer MegaByte-große Java-Klassen schreibt, und deswegen meint,
die Datei aufsplitten zu wollen, sollte sowieso mal woanders nach seinem
Denkfehler suchen.

Die GUI von der Logik zu trennen, ist von Haus aus üblich.

 

[schalentier]

Ich verstehs net, nimm halt 2 Klassen... wozu noch ein Keyword? Du kannst auch die eine von der andren ableiten... aber noch ein Sprachkonzept, um Files zusammenzufuegen? KA... ich seh keinen Nutzen dabei...

 

[Guest]

Partial dient eigentlich nicht dazu 2 Klassen zu "verbinden" sondern lediglich eine Klasse auf mehrere Dateien aufzuteilen. Damit der Compiler weis, das der Quellcode einer Datei nur einen Teil einer Klasse darstellt muss diese partial deklariert werden. Die endgültige Klasse wird aus diesen Teilen zusammengesetzt.

Wie gesagt gibt es aber solch ein Konstrukt in Java nicht.

Ja ich sag ja, dass es eine Klasse in zwei Files aufspaltet.

... und wer MegaByte-große Java-Klassen schreibt, und deswegen meint,
die Datei aufsplitten zu wollen, sollte sowieso mal woanders nach seinem
Denkfehler suchen.

Die GUI von der Logik zu trennen, ist von Haus aus üblich.

Hat nichts mit grösse zu tun!

Ich verstehs net, nimm halt 2 Klassen... wozu noch ein Keyword? Du kannst auch die eine von der andren ableiten... aber noch ein Sprachkonzept, um Files zusammenzufuegen? KA... ich seh keinen Nutzen dabei...

Ordnung! Meine Ansicht ist, dass Java ein wenig "unordentlicher" als C# ist...

Aber da Niemand eine Möglichkeit kennt eine Klasse auf 2 Dateien zu spalten sehe ich das Thema als geschlossen an.

--THREAD GESCHLOSSEN--

 

[MrDude]

Hoppala, war ja garnicht angemeldet

 

[Wildcard]

Ordnung! Meine Ansicht ist, dass Java ein wenig "unordentlicher" als C# ist...

Ich sag's mal so, du bist es aus C# so gewohnt.
Die meisten Java Leute stehen diesem C# 'Feature' eher kritisch gegenüber (Genau wie GOTOs, Operatorenüberladung und Properties).

Aber da Niemand eine Möglichkeit kennt eine Klasse auf 2 Dateien zu spalten sehe ich das Thema als geschlossen an.

Diese Möglichkeit existiert definitiv nicht.

 

[MrDude]

Ordnung! Meine Ansicht ist, dass Java ein wenig "unordentlicher" als C# ist...

Ich sag's mal so, du bist es aus C# so gewohnt.
Die meisten Java Leute stehen diesem C# 'Feature' eher kritisch gegenüber (Genau wie GOTOs, Operatorenüberladung und Properties).

Natürlich, darum sag ich ja "Meine Ansicht..." (wobei Überladungen und Props wirklich praktisch sind, GOTO hab ich bis jetzt noch nie benutzt...)

 

[Wildcard]

Ich hab einfach mal den ersten Link aufgegriffen:
http://cafe.elharo.com/java/operator-overloading-considered-harmful/

 

[Guest]

Die meisten Java Leute stehen diesem C# 'Feature' eher kritisch gegenüber (Genau wie GOTOs, Operatorenüberladung und Properties).

Also Properties finde ich wirlich nett.

 

[Wildcard]

Kann man mögen, muss man aber nicht.
Ich mag getter/setter, weil sie mit hilfe von IntelliSense einen sehr guten Überblick über das Objekt liefern (alles gängt mit dem gleichen Buchstaben an).
Ich sehe den großen Vorteil von Properties nicht wirklich, daher kann ich sehr gut auf zusätzliche Compiler-Magic verzichten.

 

[Guest]

Der Vorteil ist einfach Bequemlichkeit beim Programmieren. Vom Standpunkt des Zugriffsschutzes gibt es keinen Unterschied.

 

[Wildcard]

Der Vorteil ist einfach Bequemlichkeit beim Programmieren.

Und genau den sehe ich nicht weil ich eine IDE benutze und sowas niemals ausschreibe.

 

[Guest]

In der Bean-Klasse ist der Unterschied nicht so groß, aber beim Zugriff schreibt man statt person.getName() einfach person.name

 

[Wildcard]

Und das erledigt eben die IDE.
Bei neuen Objekten schaue ich mir auch Grundsätzlich erstmal mit IntelliSense die getter und setter an um einen Überblick zu erhalten. Da finde ich die Namenskonvention sehr praktisch.
Man kann sich drüber streiten, ich vermisse es bei Java nicht.

 

[Roar]

IntelliSense gipts nur in visual studio :bae:

 

[Wildcard]

grml... dann eben AutoCompletion oder whatever :bae:

 

[Guest]

Der vermeintliche Zugriffsschutz bei gettern/settern ist oft trügerisch, da ein per get erhaltenes Objekt meist nur eine Referenz auf eine Instanzvariable liefert, statt einer Referenz auf eine Kopie.

 

[Wildcard]

Dieser Punkt muss in der API-Doc geklärt werden.
Hier muss der 'Vertrag' der Methode festgelegt werden.