Member-Variable erzwingen

[Rock Lobster]

Hallo,

wie schaffen es die Swing-Komponenten eigentlich, ein serialVersionUID zu "erzwingen"? Okay, man muß es nicht hinzufügen, aber immerhin wird eine Warning angezeigt, wenn man es nicht macht.

Ist das mit normalen Java-Sprachrfeatures irgendwie machbar? Oder ist das eher ein Hack von Sun? Oder möglicherweise von Eclipse?

 

[Noar]

Kein "Hack" von Sun oder ein Eclipse-Feature, sondern ein "Feature" von Java. Ich meine, das wurde mit 1.5 eingeführt.

Kommt in allen Klassen, die das Interface "java.io.Serializable" verwenden, bzw. abgeleiteten Klassen, vor.

Siehe auch: http://java.sun.com/javase/6/docs/api/java/io/Serializable.html

 

[Rock Lobster]

Okay, es ist also mit herkömmlichen Sprachmitteln nicht nachbaubar? Weil das Serializable-Interface ist ja leer...

 

[maki]

Verstehe die Frage nicht.

Serializable ist ein sog. "Marker Interface", keine Methoden, sondern ein Signal für den Compiler, diese Klasse speziell zu behandeln da sie serialisiert werden muss.

Marker INterfaces sind nicht unüblich, es kann auch sein das es sich dabei "nur" um ein Signal für den Entwickler handelt.

 

[Rock Lobster]

Naja ob es für mich als kleinen Java-Entwickler ebenfalls möglich ist, bestimmte Member zu "erzwingen", oder ob das - kurz gesagt - nur Sun kann

Also so wie ich das verstanden habe, wurde der Compiler extra daraufhin umprogrammiert, daß er eben bei Klassen, die Serializable implementieren, eine Warnung erzeugt, wenn die serialVersionUID fehlt. Somit ist es also nicht mit "herkömmlichen" Java-Sprachmitteln gemacht, sondern einfach ausgedrückt ein "Compiler-Hack". Somit habe ich als Entwickler keine Möglichkeit, ähnliches zu machen, z.B. ebenfalls ein Interface oder eine abstrakte Klasse, die die Benutzung bestimmter Member voraussetzt. Das war es nur, was ich wissen wollte

 

[maki]

Achso...

Member sind interne(!) Details die nicht vorgeschrieben werden sollten imho, vorschreiben kann man Schnittstellen (Methoden), entweder über Interfaces oder abstrakte Basisklassen.

 

[Rock Lobster]

Jo schon klar, aber mich hat's irgendwie interessiert... manchmal wär's z.B. nett wenn man z.B. einen static final String NAME oder DESCRIPTION vorgeben könnte. Natürlich geht das auch indem man einfach die Methoden getName() und getDescription() vorgibt, aber wäre halt evtl. 'ne Alternative...

 

[Tobias]

Konstanten kannst du via Interfaces vorgeben. Nur mit Instanz- und Klassenvariablen wirst du wenig Glück haben (Man könnte natürlich eine abstrakte Klasse haben, die als Obertyp genutzt werden muß, wird aber blöd wegen Einfach-Implementierungsvererbung).

mpG
Tobias

 

[maki]

Konstanten kannst du via Interfaces vorgeben.

Nana, wieso denn schlechte Praktiken bzw. Anti-Pattern empfehlen

 

[Tobias]

Naja, dass man das auch mißbrauchen kann, ist klar. Aber wenn es einen gerechtfertigten Anwendungsgrund gibt - warum nicht?

mpG
Tobias

P.S.: <klugscheiß>Sowas wie Anti-Pattern gibt es nicht. Es ist ein Muster (Pattern), wenn auch ein möglicherweise schlechtes.</klugscheiß>

 

[maki]

Solltest das Klugscheissen schon besser beherrschen wenn du mitmischen willst

Anti-Pattern: http://en.wikipedia.org/wiki/Anti-pattern

Warum Interfaces mit Konstanten ein Anti-Pattern ist: http://java.sun.com/j2se/1.5.0/docs/guide/language/static-iport.html
http://personalwebs.coloradocollege.edu/~sjanke/Tutorial/java/interpack/staticimport.html
Dafür gibt es jetzt die static imports.

 

[Tobias]

Das es den Begriff Anti-Pattern gibt, ist mir bekannt. Aber letztlich ist das nur ein Begriff, der aus Marketinggründen für das griffigere und treffendere "Bad practice" gewählt wurde (Hey, ein Buch mit "Pattern" im Titel verkauft sich immer noch verdammt gut.). Das der Begriff wenig bis keinen Sinn ergibt, mußt du zugeben .

Die beiden Links zur "Bad Practice Kontanten im Interface" lese ich mir mal durch, vielleicht findet sich ja ein Hinweis, warum das Einfügen von sinnigen, zur Schnittstelle dazugehörigen Konstanten "bad" sein soll.

mpG
Tobias

 

[maki]

Das es den Begriff Anti-Pattern gibt, ist mir bekannt. Aber letztlich ist das nur ein Begriff, der aus Marketinggründen für das griffigere und treffendere "Bad practice" gewählt wurde (Hey, ein Buch mit "Pattern" im Titel verkauft sich immer noch verdammt gut.). Das der Begriff wenig bis keinen Sinn ergibt, mußt du zugeben icon_smile.gif.

Genauso gut kann man Pattern als Best-Practices bezeichnen...

Da man allerdings schhon Pattern dazu sagt, kann man das Gegenstück, Bad-Practices, auch gleich Anti-Pattern nennen.
Marketing ist beides, nimmt sich nix

Man muss sich halt nur gegenseitig verstehen und deswegen ist es von Vorteil, dieselben Begriffe mit denselben Bedeutungen zu verwenden

Ob best/bad practices, Pattern/Anti Pattern ist mir persönlich wurscht.

Die beiden Links zur "Bad Practice Kontanten im Interface" lese ich mir mal durch, vielleicht findet sich ja ein Hinweis, warum das Einfügen von sinnigen, zur Schnittstelle dazugehörigen Konstanten "bad" sein soll.

Solltest du unbedingt, ist eigentlich schon lange bekannt
Es DER Grund für static imports.
Die Probleme gehen damit los, das interfaces meist public sind, und Konstanten meist Implementierungsdetails... ausserdem sind Interfaces nicht dafür gemacht, um bequem Konstanten zu veröffentlichen, ein Missbrauch mit hässlichen Konsequenzen.

Blochs Buch ist sehr empfehlenswert, wenn auch in manchen Dingen überholt.
Zum Glück kommt diesen Herbst die 2nd Edition.

 

[tfa]

vielleicht findet sich ja ein Hinweis, warum das Einfügen von sinnigen, zur Schnittstelle dazugehörigen Konstanten "bad" sein soll.

Das ist es nicht. Dieses Anti-Pattern bezieht sich nur auf Interfaces, die ausschließlich Konstanten beinhalten und nur aus Schreibfaulheit verwendet werden (bzw. wurden).
Gegen Konstanten in normalen Schnittstellen (die auch noch "sinnig" und "dazugehörig" sind) wird niemand etwas haben.

 

[Tobias]

Also Interfaces die nur Konstanten enthalten, fand ich schon immer "häßlich" und habe sie in den fünf Jahren meiner Java-Programmiertätigkeit auch nie benutzt. Konstanten gehören generell nur selten in ein Interface, da sind wir einer Meinung. Aber trotzdem kommt es (speziell bei Factories) hin und wieder in meinen Projekten vor, das für jede Produktgruppe die produziert werden können soll, eine Konstante im Interface hinterlegt ist. Ich weiß, eigentlich gibt es dafür Enums, aber manchmal ist es ja sinnvoll selbst festlegen zu können, welchen Wert die Konstanten letztlich haben - zum Beispiel für Bitschiebereien.

Und zu den Patterns (sorry, ich kann's mir nicht verkneifen): Die GoF hat sich einfach ein paar Muster der Softwareentwicklung gegriffen und diese neutral benannt. Das das zufällig alles positive Muster waren, heißt nicht, das "Pattern" plötzlich für "Best Practice" steht. Aber natürlich hast du recht, dass es hauptsächlich darum geht, einander zu verstehen. Was mit Antipattern gemeint ist, ist mir ja auch klar. Genau wie bei "gedownloadet" ...

mpG
Tobias

Edit: "Benutzt" habe ich Konstanten-Interfaces schon ab und zu (z.B. SwingConstants), aber geschrieben habe ich noch nie eins.

 

[maki]

Also Interfaces die nur Konstanten enthalten, fand ich schon immer "häßlich"

Dann sind wir uns ja einig

Und zu den Patterns (sorry, ich kann's mir nicht verkneifen): Die GoF hat sich einfach ein paar Muster der Softwareentwicklung gegriffen und diese neutral benannt. Das das zufällig alles positive Muster waren, heißt nicht, das "Pattern" plötzlich für "Best Practice" steht.

Naja, kommt auf die Anwndung an ob es positiv oder negativ ist.
zB. ist das Singleton so wie es von den meisten verwendet wird ein sog. "Anti-Pattern"

 

[Rock Lobster]

Naja mir ging's eigentlich nicht direkt um Konstanten, die bereits feststehen, sondern eher so darum, zu definieren, DASS eine Implementierung bzw. Ableitung einer Klasse diese Konstante definieren MUSS.

Aber wie gesagt, sowas ist letztendlich lösbar indem man einfach ein getName() statt NAME definiert, denn ein getName() kann ich vorab schon in einer abstrakten Klasse benutzen, und dann erzwingen, daß die abgeleitete Klasse dieses getName() auch implementiert.

 

[Janus]

meine frameworks sind vollgestopft mit konstanten feldern in interfaces ich finds einfach schöner, auf diese art eindeutige identifier für meine factories zu erzeugen, als irgendwas über reflection zusammenzuwürfeln.

interfaces, die lediglich als eimer für nen haufen konstanten herhalten sind aber tatsächlich ne eklige nummer.