|
Community Links |
Interessengemeinschaften |
Benutzerliste |
Foren durchsuchen |
Stichwortsuche |
Erweiterte Suche |
Uns unterstützen |
Shoppen bei Amazon |
Spende per Patreon |
Spende per PayPal |
Spende per Steady |
alle Möglichkeiten |
Gehe zu... |
|
Themen-Optionen | Ansicht |
2005-10-27, 19:46:36 | #1 (im Thread / einzeln) |
Avantgarde Member
Registriert: 2004-05-15
Ort: Österreich
Beiträge: 5.578
|
Java + Schlüsselwort "extends"
Ich hab mal von einer Möglichkeit gehört, mit der man einfach mit dem Schlüsselwort extends überprüfen kann, ob eine Klasse von einer anderen ableitet.
Also statt der bisherigen Methode: gibts anscheinend eine vereinfachte Methode, zb so ähnlich wie: Kann das sein? Und wenn ja wie gehts richtig? Danke! Intel Core i7 5820K | MSI X99s SLI Plus | 16GB DDR4-2400 RAM | Inno3D GeForce GTX 970 | Creative Blaster Z | 1x Western Digital WD10 EZRX | 1x Samsung SSD 850 EVO | Win 10 LG 60UF850V | Onkyo TX NR535 | Teufel Concept S | Samsung BD-P 1500 Geändert von RMC (2005-10-27 um 19:46:59 Uhr) |
2005-10-27, 19:58:11 | #2 (im Thread / einzeln) |
Admiral Member
Registriert: 2005-08-16
Ort: Zürich
Beiträge: 2.160
|
Re: Java + Schlüsselwort "extends"
Nein, das kann so nicht sein. Du vermischt da zwei Dinge.
Für das, was du tun willst, ist richtig: Ab Java5 gibt es bei den Generics eine Schreibweise, die etwas Ähnliches macht und mit "extends" funktioniert: Damit sagst du, dass für das Typargument der Klasse MyClass<T> T instanceof Collection == true gelten muss. Jetzt muss ich noch erwähnen: Wann immer du "instanceof" brauchst, solltest du dir überlegen, ob du nicht gerade an einem Workaround um einen Design-Fehler werkelst. "instanceof" hat in der OOP eigentlich nichts zu suchen. Geändert von Abnaxos (2005-10-27 um 20:28:14 Uhr) |
2005-10-27, 20:07:48 | #3 (im Thread / einzeln) |
Platinum Member
|
Re: Java + Schlüsselwort "extends"
Richtig, denn anstatt jedesmal bevor man eine Operation ausführt auf Typenkompatibilität überprüfen muss, hat man einen Designerfehler.
Was er hier meint ist, dass man zu gleichen Klassen ein abstrakte Oberklasse haben sollte,denn somit wird ein instanceof überflüssig. |
2005-10-27, 20:46:53 | #4 (im Thread / einzeln) |
Avantgarde Member
Threadstarter Registriert: 2004-05-15
Ort: Österreich
Beiträge: 5.578
|
Re: Java + Schlüsselwort "extends"
äh...ich hab eine abstrakte Oberklasse und 2 Klassen, die von dieser ableiten, aber ich komm um ein "instanceof" bzw. um einen Typcheck trotzdem nicht herum. Intel Core i7 5820K | MSI X99s SLI Plus | 16GB DDR4-2400 RAM | Inno3D GeForce GTX 970 | Creative Blaster Z | 1x Western Digital WD10 EZRX | 1x Samsung SSD 850 EVO | Win 10 LG 60UF850V | Onkyo TX NR535 | Teufel Concept S | Samsung BD-P 1500 |
2005-10-27, 20:47:33 | #5 (im Thread / einzeln) |
Avantgarde Member
Registriert: 2003-10-26
Beiträge: 6.880
|
Re: Java + Schlüsselwort "extends"
In den meisten Fällen ist es sinnvoller instanceof durch das Visitor-Pattern oder eine Programmiersprache mit multi-dispatch zu ersetzen.
Ich empfehle das 2. wenn keine Rahmenbedingungen dagegen sprechen. |
2005-10-27, 20:47:52 | #6 (im Thread / einzeln) |
Master Member
Registriert: 2004-04-07
Beiträge: 8.960
|
Re: Java + Schlüsselwort "extends"
Das ist so nicht ganz richtig. Es gibt ja zum Beispiel das schöne Design Pattern mit Marker-Interfaces indem über die Implementierung eines (leeren) Interfaces eine Klasse markiert wird, sodass sie gesondert behandelt werden kann. Das ganze nutzen afaik auch zum Teil Java Klassen, bestes Beispiel ist afaik Serializable oder auch Remote, das sind beides Marker-Interfaces. Geändert von Senior Sanchez (2005-10-27 um 20:48:40 Uhr) |
2005-10-27, 20:56:21 | #7 (im Thread / einzeln) |
Admiral Member
Registriert: 2005-08-16
Ort: Zürich
Beiträge: 2.160
|
Re: Java + Schlüsselwort "extends"
Naja, ich habe ja auch geschrieben: "Man sollte sich überlegen, ob nicht ein Design-Fehler vorliegt" -- das heisst nicht zwingend, dass es einer sein muss. Natürlich gibt es Ausnahmen, gerade in Frameworks oder Containern für Komponenten können solche Konstruktionen in der Tat sehr praktisch sein.
Ab Java5 würde ich dieses Beispiel allerdings mit Annotations lösen. Im Prinzip ist auch das Marker-Interface nur ein Workaround um fehlende Features in der Sprache. Ein anderes Beispiel ist das bekannte Konstanten-Interface, das seit Java5 eigentlich durch Enumerations und Static Imports ersetzt ist. Geändert von Abnaxos (2005-10-27 um 21:10:47 Uhr) |
2005-10-27, 22:52:21 | #9 (im Thread / einzeln) |
Admiral Member
Registriert: 2003-03-27
Beiträge: 3.357
|
Re: Java + Schlüsselwort "extends"
Nein
Jetzt muss ich noch erwähnen: Wann immer du "instanceof" brauchst, solltest du dir überlegen, ob du nicht gerade an einem Workaround um einen Design-Fehler werkelst. Und an machen Orten kommt man halt nicht darum rum, weil statische Typinformation verlorenging. z.B. Swing/AWT EventListener .. and it’s not “oh just thread your application”. Anyone that says that is basically an idiot, not appreciating the problems. Geändert von HellHorse (2005-10-27 um 22:54:23 Uhr) |
2005-10-27, 23:45:57 | #10 (im Thread / einzeln) |
Avantgarde Member
Registriert: 2003-10-26
Beiträge: 6.880
|
Re: Java + Schlüsselwort "extends"
Vielleicht hilft http://www-igm.univ-mlv.fr/~forax/works/sprintabout/, es passt vom Design allerdings nicht wirklich in Java. Trotzdem könnte es in manchen Fällen ganz nützlich sein.
|
2005-10-28, 03:16:37 | #11 (im Thread / einzeln) |
Admiral Member
Registriert: 2005-08-16
Ort: Zürich
Beiträge: 2.160
|
Re: Java + Schlüsselwort "extends"
Stimmt eigentlich und Trap hat Recht. Dummerweise kann man die Systemklassen von Java nicht ändern und so kann man in String oder Date halt nicht eben mal schnell ein Interface implementieren. Aber classextensions sind ja so pöse. Verschiedenste Teil-Projekte, auf 10 und mehr Entwickler verteilt, die nur mässig miteinander kommunizieren, sind in der Java-Entwicklung die Regel. Wenn da sämtliche beteiligten Entwickler einfach so die Möglichkeit hätten, das Verhalten von String zu ändern (das schliesst die Entwickler von externen Libraries mit ein, wir reden also von weit mehr als 10, auch von solchen, deren Namen wir nichtmal kennen), dann wäre das fatal. Nein, es ist schon OK, dass da klare Verhältnisse herrschen, auch wenn man diese häufig gerne ändern würde. Geändert von Abnaxos (2005-10-28 um 03:38:47 Uhr) |
2005-10-28, 12:58:43 | #12 (im Thread / einzeln) |
Admiral Member
Registriert: 2003-03-27
Beiträge: 3.357
|
Re: Java + Schlüsselwort "extends"
Vielleicht hilft http://www-igm.univ-mlv.fr/~forax/works/sprintabout/, es passt vom Design allerdings nicht wirklich in Java. Trotzdem könnte es in manchen Fällen ganz nützlich sein. In Java kann natürlich eine Klasse niemals ein Exemplar (eine Instanz) einer anderen Klasse sein (was in anderen Sprachen nicht gelten muss). sinngemäss:
Verschiedenste Teil-Projekte, auf 10 und mehr Entwickler verteilt, die nur mässig miteinander kommunizieren, sind in der Java-Entwicklung die Regel. Wenn da sämtliche beteiligten Entwickler einfach so die Möglichkeit hätten, das Verhalten von String zu ändern (das schliesst die Entwickler von externen Libraries mit ein, wir reden also von weit mehr als 10, auch von solchen, deren Namen wir nichtmal kennen), dann wäre das fatal. Aber wenn massive Änderungen an der dokumentierten Verhaltensweise einer Klasse einfach so ohne weiteres möglich sind, u.U. in einem von 20 am Endprodukt beteiligten Projekten gut Versteckt, dann muss ich sagen: Gottseidank erlaubt Java keine Mixins! Irgend eine Möglichkeit einer Klasse bestehendes Verhalten hinzuzufügen ohne Vererbung wäre aber schon gut. Ok, Mixins sind nicht ideal, aber etwas in der Richtung von Traits oder Modules in Ruby wäre schon gut. z.B dass man in Interfaces Code schreiben darf, der auf keine Instanzvariablen zugreifft. (Natürlich braucht man dann immer noch aliasing oder eine andere Form der Konfliktauflösung) Schreib mal eine eigene Collection oder Stream Hierarchie und du weisst, was ich meine. Wenn man keine Mixins machen kann, wird einem das häufig einen bösen Knüppel zwischen die Beine werfen, wo man gerne etwas nachhelfen würde -- es wäre doch so einfach, wenn ... Hier stellt sich auch gleich die Frage, ob Zugriffskontrolle überhaupt eher ein Werkzeug oder ein Hindernis ist.
.. and it’s not “oh just thread your application”. Anyone that says that is basically an idiot, not appreciating the problems. |
2005-10-29, 01:00:16 | #13 (im Thread / einzeln) |
Platinum Member
|
Re: Java + Schlüsselwort "extends"
äh...ich hab eine abstrakte Oberklasse und 2 Klassen, die von dieser ableiten, aber ich komm um ein "instanceof" bzw. um einen Typcheck trotzdem nicht herum. Wenn du in der abstrakten(muss nicht) eine gemeinsame Methode hast,die von deinen beiden Klassen geerbet werden,brauchst du die Abfrage nicht mehr, du führst die Operation aus mit dem Cast zur Oberklasse. |
2005-10-29, 01:10:03 | #14 (im Thread / einzeln) |
Master Member
Registriert: 2004-04-07
Beiträge: 8.960
|
Re: Java + Schlüsselwort "extends"
Ich habe da schon wieter gedacht.Stichwort dynamisches Binden! Mal ne OT-Frage: Spricht man in diesem Fall eigentlich von Cast? Weil nen Casting ist ja ne explizite Typumwandlung, aber ein Objekt das augenscheinlich auf einen Typ "umgewandelt" wird, der in der eigenen Vererbungshierarchie ist, das ist ja keine Typumwandlung, da das Objekt ja eigentlich Typ der Klasse bereits ist. Das JDK schmeißt nach fehlerhaften Objekt-"Castings" ja gerne ne ClassCastException, aber die Frage ist, ob das halt überhaupt nen cast ist. lol, ist jetzt etwas verwirred, aber ums mal kurz zu machen: class A extends B private a = new A(); ((B)a).irgendetwas(); // ist das an dieser Stelle ein Cast? weil es ist ja eigentlich keine Typumwandlung Geändert von Senior Sanchez (2005-10-29 um 01:13:56 Uhr) |
2005-10-29, 16:30:35 | #16 (im Thread / einzeln) |
Admiral Member
Registriert: 2005-08-16
Ort: Zürich
Beiträge: 2.160
|
Re: Java + Schlüsselwort "extends"
Es geht ja nicht um das Ändern von Verhalten, es geht um das Hinzufügen von Verhalten. Zum Beispiel ein #isEmtpy() in String, oder halt eben ein #accept für einen bestimmten Visitor. Ich kann wirklich nicht erkennen, was daran schelcht oder gefährlich sein soll. Was haben denn bitte Mixins mit dem 'massive Änderungen an der dokumentierten Verhaltensweise einer Klasse' zu tun? OK, das Beispiel ist etwas gesucht, aber du verstehst, was ich meine. Auch wenn man es nur auf's hinzufügen beschränkt, kann es gefährlich werden. Nehmen wir String#isEmpty(). Irgendwas in den Jakarta Commons fügt als der Klasse String eine Methode isEmpty() hinzu, die true liefert, falls der String leer ist oder nur aus Whitespaces besteht. Nun ziehen wir noch eine weitere Bibliothek ins Projekt, die fügt String eine Methode isEmpty() hinzu, die aber gibt true zurück, wenn string.length()==0 ist. Welche Variante von #isEmpty() wird nun verwendet? Eine der beiden Libraries wird nicht mehr korrekt funktionieren. In Objective-C musste ich jedenfalls bitter lernen, wie schnell es geht, bis man derartige Konflikte hat und eine Kategorie einfach stillschweigend eine andere verdeckt und irgendwo irgendetwas plötzlich nicht mehr funktioniert. class A extends B |
2005-10-29, 19:19:47 | #17 (im Thread / einzeln) |
Avantgarde Member
Registriert: 2003-10-26
Beiträge: 6.880
|
Re: Java + Schlüsselwort "extends"
Auch wenn man es nur auf's hinzufügen beschränkt, kann es gefährlich werden. Nehmen wir String#isEmpty(). Irgendwas in den Jakarta Commons fügt als der Klasse String eine Methode isEmpty() hinzu, die true liefert, falls der String leer ist oder nur aus Whitespaces besteht. Nun ziehen wir noch eine weitere Bibliothek ins Projekt, die fügt String eine Methode isEmpty() hinzu, die aber gibt true zurück, wenn string.length()==0 ist. Welche Variante von #isEmpty() wird nun verwendet? Eine der beiden Libraries wird nicht mehr korrekt funktionieren. Bietet keine Sprache dafür eine sinnvolle Lösung (wie die von mir beschriebene)? Geändert von Trap (2005-10-29 um 19:39:01 Uhr) |
2005-10-29, 19:53:09 | #18 (im Thread / einzeln) |
Admiral Member
Registriert: 2003-03-27
Beiträge: 3.357
|
Re: Java + Schlüsselwort "extends"
Mal ne OT-Frage: Spricht man in diesem Fall eigentlich von Cast? Weil nen Casting ist ja ne explizite Typumwandlung, aber ein Objekt das augenscheinlich auf einen Typ "umgewandelt" wird, der in der eigenen Vererbungshierarchie ist, das ist ja keine Typumwandlung, da das Objekt ja eigentlich Typ der Klasse bereits ist. Es könnte ja z.B. einer auf die Idee kommen, #equals() und #hashCode() von ArrayList so zu ändern, dass #equals() dann true zurückliefert, wenn für alle Elemente "equal" sind. http://java.sun.com/j2se/1.5.0/docs/...a.lang.Object) http://java.sun.com/j2se/1.5.0/docs/...tml#hashCode() Was wir hier diskutieren, das hinzufügen von Methoden zu einer Klasse, welche in ein anderes Paket/einen anderen Namespace gehören, kenne ich unter dem Namen classextensions. Unter Mixins verstehe ich Klassen, welche per Superklasse parametrisierbar sind. Das eine hat mit dem anderen nix zu tun. @Trap Das von dir beschriebene Konzept kenne ich unter dem Namen classboxes. Damit lassen sich lustige Sachen machen wie Klassen lokal neu definieren. Gibt afaik Implementationen für Squeak und Java. .. and it’s not “oh just thread your application”. Anyone that says that is basically an idiot, not appreciating the problems. |
2005-10-30, 02:51:13 | #19 (im Thread / einzeln) |
Admiral Member
Registriert: 2005-08-16
Ort: Zürich
Beiträge: 2.160
|
Re: Java + Schlüsselwort "extends"
Was wir hier diskutieren, das hinzufügen von Methoden zu einer Klasse, welche in ein anderes Paket/einen anderen Namespace gehören, kenne ich unter dem Namen classextensions. Unter Mixins verstehe ich Klassen, welche per Superklasse parametrisierbar sind. Das eine hat mit dem anderen nix zu tun. Google hat halt zu "Class Extension" nichts vernünftiges ausgespuckt und der Hinweis auf C# ist in diesem Thread auch nirgends gefallen ... |
2005-10-30, 08:47:05 | #20 (im Thread / einzeln) |
Admiral Member
Registriert: 2003-03-27
Beiträge: 3.357
|
Re: Java + Schlüsselwort "extends"
OK, du redest also von dem Ding, das in C# 2.0 zu finden sein wird. Eigentlich ist es uralt (Smalltalk kennt es vermutlich länger, als ich schon auf der Welt bin) und kommt nicht von Micro$~1, aber das überrascht uns ja nicht wirklich. Google hat halt zu "Class Extension" nichts vernünftiges ausgespuckt .. and it’s not “oh just thread your application”. Anyone that says that is basically an idiot, not appreciating the problems. Geändert von HellHorse (2005-10-30 um 08:48:52 Uhr) |
Lesezeichen |
Ansicht |
Linear-Darstellung |
Zur Hybrid-Darstellung wechseln |
Zur Baum-Darstellung wechseln |
|
|