const in Java und interface's ...
-
ich weiß nich genau was du meinst? aber sowas geht:
class vector<T> implements const_vector<T> class vector<T> implements const_vector<? super T>
-
jana generics schrieb:
ich weiß nich genau was du meinst? aber sowas geht:
class vector<T> implements const_vector<T> class vector<T> implements const_vector<? super T>Das letztere sieht schon so aus, als ob es in die richtige Richtung geht (btw, schließt der Ausdruck <? super T> auch T selber mit ein?). Ich dachte eher an einen Ansatz, daß mein Datenyp irgendwo sagen kann "mein const-interface ist XYZ" (in C++
class text{typedef const_test const_interface;...}) und daß vector<X> dann das Interface const_vector<x::const_interface> implementieren sollte).(btw, kann man bei Java Methodenüberschreibung auch die Parameter- und Rückgabetypen nachbessern? Sprich: gilt die 'test element(int);' in vector<test> als Definition der 'const_test element(int);' aus dem (von vector<test> implementierten) Interface const_vector<const_test>?
-
CStoll schrieb:
Das letztere sieht schon so aus, als ob es in die richtige Richtung geht (btw, schließt der Ausdruck <? super T> auch T selber mit ein?). Ich dachte eher an einen Ansatz, daß mein Datenyp irgendwo sagen kann "mein const-interface ist XYZ" (in C++
class text{typedef const_test const_interface;...}) und daß vector<X> dann das Interface const_vector<x::const_interface> implementieren sollte).meinst du sowas:
class Vector<T extends ConstInterface> implements ConstVector<T>
(btw, kann man bei Java Methodenüberschreibung auch die Parameter- und Rückgabetypen nachbessern? Sprich: gilt die 'test element(int);' in vector<test> als Definition der 'const_test element(int);' aus dem (von vector<test> implementierten) Interface const_vector<const_test>?
wenn test eine unterklasse von const_test ist, oder wenn die methode als 'T element(int)' (was wohl eher sinn machen würde) ja
-
asfasfasf schrieb:
CStoll schrieb:
Das letztere sieht schon so aus, als ob es in die richtige Richtung geht (btw, schließt der Ausdruck <? super T> auch T selber mit ein?). Ich dachte eher an einen Ansatz, daß mein Datenyp irgendwo sagen kann "mein const-interface ist XYZ" (in C++
class text{typedef const_test const_interface;...}) und daß vector<X> dann das Interface const_vector<x::const_interface> implementieren sollte).meinst du sowas:
class Vector<T extends ConstInterface> implements ConstVector<T>
so ähnlich - class Vector<T extends ConstInterface> implements ConstVector<ConstInterface> - wobei allerdings jedes T sein eigenes ConstInterface mitbringt (String als immutable Klasse sich selber, die 'test' von oben hat 'const_test' etc.)
-
Ich würde dir raten dich einfach an das zu halten, was die Sprache vorsieht. Java kennt (wie viele andere Sprachen auch) halt einfach keine const-correctness. Hier wurden natürlich schon viele Beispiele gebracht, die die ach so schlimmen Folgen von fehlender const-correctness zeigen, aber komischerweise musste ich noch nie in einem Programm Autos mit Farben und dergleichen nachbilden. Man muss halt einfach ein Gefühl dafür entwickeln, welche Typen man besser immutable gestaltet und dann gibt es auch keine Probleme. Zusätzlich ist es mir manchmal auch schon passiert, dass ich im Nachhinein froh darüber war, dass ich manches nicht konstant übergeben habe (gut, ich hatte natürlich kein const-correctness, aber ich habe überlegt, ob ich eine immutable Wrapper erstellen soll), weil dann doch ein sinnvoller Verwendungszweck für eine Änderung aufkam. Das ist halt ungefähr so wie mit versiegelten Klassen oder Methoden, da sie am Anfang zwar ganz nett wirken (hier: "bessere" Performance), aber man sich im Nachhinein dann doch manchmal wünscht, dass man es nicht getan hätte.
-
Edit: Naja, blödes Beispiel, außerdem könnte ConstMessage einfach kein Interface für setNewMessage() anbieten...
ja das beispiel ist schon irgendwie blöd wenn die klasse selber schon ConstMessage heißt wär eine methode setMessage() bissl blöde
############################
nein, das willst du nicht. was die klasse innerhalb ihrere methoden macht ist *ihre* sache. wenn sie es für nötig hält bei einem getFarbe() aufruf zu beschleunigen soll sie das tun. das ist eine sache der konvention und der implementierung
ok, also getFarbe() soll das Auto Rot färben, den rückwärtsgang einlegen und dann zum Mond fliegen. Klingt plausibel.
Und du willst wirklich erlauben, daß die Garage das gefundene Auto nebenbei zum Mond schießen darf?
nein, deine garage wär nicht kaputt. entweder die garage verhält sich so wie sie sich verhält oder du brauchst eine neue garage.
############################
Nein, die Garage verwaltet ihren eigenen Zustand (eine Sammlung von Autos). Mit geeignet gesetzten const's kann ich verhindern, daß sie dabei den internen Zustand dieser Autos beeinflussen kann. (Wenn ich selber die Garage entwickle, weiß ich, was sie tun darf. Aber ein Kollege sieht nur die Methoden der Auto-Klasse und könnte auf die Idee kommen, sie auch zu nutzen.)
Sorry, wenn Eure Auto so geschnitten sind, dass sie eine Änderung der Farbe zulassen, dann seid Ihr selbst schuld. Wenn ich die Möglichkeiten zur Verfügung stelle, dann muss ich mich nicht wundern, wenn sie benutzt werden.
###########################
Sieht soweit nicht gut aus fuer Const-Correctness.
Koennt ihr vielleicht noch Stellung zu den Argumenten von http://c2.com/cgi/wiki?AvoidConstCompletely beziehen?ConstIsaVirus. Declare a pointer/reference to be const; and the TransitiveClosure? of places that pointer/reference is passed will also need to be declared const. Or else you'll need to cast away const, and that's often a bug waiting to happen.
ConstIsaVirus is annoying when one has to make lots of edits by hand due to the ripple effect, but that nuisance is a small thing compared with the increment of correct behavior that is thereby guaranteed at compile time when used correctly, as with any kind of static type checking. Changing an int to a float is precisely as virus-like in its ripple effect.const promises very little. Const is not a synonym with "immutable"; all const means is "you can't change the object through this pointer/reference, and any place this pointer/reference is copied". There can be, of course, non-const pointers to the object which can mutate the object.
The ConstQualifier's main purpose is HelpingTheCompiler; it has almost zero use in describing the user's problem.
###########################
Kleines Beispiel:
Farbe kann immutable sein, aber was wenn man ein Komplexes Objekt hat? zB getMotor().
Wenn Motor nun Operationen hat die den Motor verändern. Beispiel: reparieren().
Wie erlauben wir einem Client einen View auf den Motor ohne dass er rumpfuschen darf? Motor kann nicht immutable sein. In Java würde man jetzt eine defensive Kopie machen. Funktioniert auch problemlos. Meistens hat man ja immutable Objekte und wenn mal nicht, dann halt ne defensive Kopie. Tut nicht wirklich weh. Oder man verlässt sich einfach auf den Client Code - auch sehr legitim.In C++ hat man diese Gedankengänge aber nicht: man liefert einfach einen immutable Motor. Damit kann Auto vom Client Code verlangen: du darfst den Motor ansehen, aber nicht anfassen.
Stimme soweit fuer die Sprache C++. Man schreibt einfach doppelt so viele Methoden in einer Klasse: Const und nicht Const. In Java hat man 2 Klassen, mutable und immutable.
Vorteil von C++: Keine Kopien.
Vorteil von Java: das Interface ist schlanker.
Da man sowieso zu 90% immutable braucht, ziehe ich die Methode von Java vor.
-
dsfdfg schrieb:
...
Eigentlich stimme ich da zu, ändern kann mans ja sowieso nciht so ohne weiteres, wobei ich zugebe, dass ich (so verufen das vielleicht auch bei vielen ist), z.B. das friend-Konzept manchmal gern in Java gehabt hätte. Un const ist vielleicht auch so'n Ding.
-
SammyRukka schrieb:
das friend-Konzept manchmal gern in Java gehabt hätte.
du willst in java die kapselung aushebeln mit methoden einer vorsinntflutlichen frickler-sprache?
besser als 'friend' wäre meiner meinung nach das: http://developer.apple.com/documentation/Cocoa/Conceptual/ObjectiveC/Articles/chapter_4_section_7.html#//apple_ref/doc/uid/TP30001163-CH7-TPXREF139
-
SammyRukka schrieb:
dsfdfg schrieb:
...
wobei ich zugebe, dass ich (so verufen das vielleicht auch bei vielen ist), z.B. das friend-Konzept manchmal gern in Java gehabt hätte.
dafür gibts ja den package-protected modifier
-
@beide vorher:
Ja, ich arbeite 'trotz allem' viel lieber mit Java und ja, ich kann auch ohne 'friend' gut leben und könnte mir auch ein noch eine bessere Umsetzung vorstellen, es war halt nur ein Vergleich.
Es kommt halt ab und zu vor, dass nur bestimmte Klassen etwas an einem Objekt machen können sollen und die der package/protected sind da doch nicht immer der passende Rahmen, weil man seine Packages/Hierarchien gerade in großen Projekten auch nach anderen Kriterien aufteilt.