{"id":105,"date":"2009-01-17T02:07:21","date_gmt":"2009-01-17T01:07:21","guid":{"rendered":"http:\/\/blog.adrianlang.de\/?p=105"},"modified":"2009-01-17T02:07:21","modified_gmt":"2009-01-17T01:07:21","slug":"geklonter-kaffee-ist-kalt","status":"publish","type":"post","link":"https:\/\/blog.adrianheine.de\/?p=105","title":{"rendered":"Geklonter Kaffee ist kalt"},"content":{"rendered":"

Eine unabh\u00e4ngige Kopie eines Objekts zu erhalten ist keine triviale Angelegenheit. Die zentralen Ans\u00e4tze in C++, C# und Java, diese Funktionalit\u00e4t zu realisieren, sind die Methoden \u201eClone\u201c (C#) bzw. \u201eclone<\/a>\u201c (Java) und copy-Konstruktoren<\/a>. Der folgende Beitrag konzentriert sich auf die \u201eclone\u201c-Methode in Java.<\/p>\n

Das \u201eclone\u201c-Konzept in Java besteht aus drei verschiedenen Komponenten: dem Interface \u201ejava.lang.Cloneable\u201c, der Exception \u201ejava.lang.CloneNotSupportedException\u201c und der Methode \u201eclone\u201c in \u201ejava.lang.Object\u201c. Die Methode \u201eclone\u201c ist als \u201eprotected\u201c deklariert und vermutlich nicht in Java selbst implementiert, sondern \u201enative\u201c. Sie kopiert alle Felder des Objekts in ein neues Objekt. Es wird kein Konstruktor f\u00fcr das neue Objekt aufgerufen, und die einzelnen Felder werden nicht rekursiv kopiert, sondern einfach zugewiesen. Die Methode \u00fcberpr\u00fcft, ob das aktuelle Objekt das (leere) Marker-Interface \u201ejava.lang.Cloneable\u201c implementiert. Wenn nicht, wird die Exception ausgel\u00f6st. Eine Klasse, die das Interface implementiert, sollte die Methode mit einer \u201epublic\u201c-Methode \u00fcberschreiben und \u201esuper.clone()\u201c aufrufen.<\/p>\n

Soviel zur trockenen Beschreibung. Jetzt schauen wir mal, warum das Konzept \u201ebroken by design\u201c ist: Das Interface \u201ejava.lang.Cloneable\u201c deklariert keine \u201eclone\u201c-Methode, erst recht keine \u00f6ffentliche. Das hei\u00dft ganz einfach, dass folgender Code nicht kompiliert:<\/p>\n

\r\npublic class MyUsefulClass {\r\n  public static Cloneable[] cloneMyArray(Cloneable[] myArray) {\r\n    int len = myArray.length;\r\n    Cloneable[] buf = new Cloneable[len];\r\n    for (int i = 0 ; i < len ; ++i) {\r\n      buf[i] = myArray[i].clone();\r\n    }\r\n    return buf;\r\n  }\r\n}\r\n<\/pre>\n
Nur Klassen und Interfaces, die ausdr\u00fccklich eine \u00f6ffentliche \u201eclone\u201c-Methode deklarieren, k\u00f6nnen in solchen Ausdr\u00fccken stehen.<\/p>\n
Soweit so schrecklich, aber es geht noch weiter. Java verwendet teilweise \u201eChecked exceptions\u201c, das hei\u00dft wenn eine Methode ausgef\u00fchrt wird, die eine Exception ausl\u00f6sen kann, muss die aufrufende Methode diese behandeln oder als die Exception ausl\u00f6send deklariert sein, so dass die n\u00e4chsth\u00f6here Ebene sich darum k\u00fcmmern muss. Ein durchaus interessantes Konzept mit Vor- und Nachteilen, im konkreten Fall aber eine ziemliche Katastrophe. Da die \u201eclone\u201c-Methode in \u201ejava.lang.Object\u201c als \u201ethrows java.lang.CloneNotSupportedException\u201c deklariert ist, m\u00fcssen alle sie aufrufenden Methoden (also z. B. alle \u201eclone\u201c-Methoden in abgeleiteten Klassen) diese Exception behandeln oder sie durchreichen. Da \u201ejava.lang.Object.clone\u201c aber nur dann diese Exception ausl\u00f6st, wenn das aktuelle Objekt nicht \u201ejava.lang.Cloneable\u201c implementiert, kann sich jede \u201eclone\u201c-Methode in einer Klasse, die direkt oder indirekt das Interface implementiert ziemlich sicher sein, dass sie mit dieser Exception nichts zu tun haben wird. <\/p>\n
Selbstverst\u00e4ndlich gibt es auch davon eine Ausnahme, und damit sind wir auch schon beim n\u00e4chsten gro\u00dfen Design-Problem: Ein einmal in einer Klasse implementiertes Interface klebt an jeder Unterklasse wie ein Kaugummi im Teppich. Wenn eine Klasse also partout nicht geklont werden m\u00f6chte, obwohl eine ihrer Superklassen \u201ejava.lang.Cloneable\u201c implementiert, muss sie eine eigene \u201eclone\u201c-Methode implementieren und in dieser eine Exception werfen.<\/p>\n
Ja, und dann gibt es noch ein paar unsch\u00f6ne Kleinigkeiten: \u201eclone\u201c gibt immer eine \u201ejava.lang.Object\u201c-Referenz zur\u00fcck, die erst mal gecastet werden muss. Au\u00dferdem muss die Methode auf F\u00e4higkeiten der Virtuellen Maschine zur\u00fcckgreifen, die eine Implementierung in Java sehr schwer bis unm\u00f6glich machen. Und schlie\u00dflich funktioniert klonen nicht wirklich gut mit \u201efinal\u201c-Feldern.<\/p>\n
Also noch mal zusammengefasst: Das Clone-Design in Java erm\u00f6glicht es, dass eine Klasse \u201ejava.lang.Cloneable\u201c implementiert aber keine \u201eclone\u201c-Methode hat und zwingt Klassen, die wissen, dass keine Exception auftreten kann zu einer Exception-Behandlung.<\/p>\n
Links<\/h3>\n