StringBuilder<\/code>.<\/p>\n\/\/ F muss von allen konkreten Subklassen mit sich selbst belegt werden, was nicht erzwingbar ist\r\n\r\nabstract class FluentBase<F extends FluentBase<F>> {\r\n\r\n\tprivate String value;\r\n\r\n \tprivate F getThis() {\r\n\r\n \t \treturn (F) this; \/\/ Warnung: unchecked cast\r\n\r\n \t}\r\n\r\n\tpublic F withValue(String value) {\r\n\r\n\t\tthis.value = value;\r\n\r\n\t\treturn getThis();\r\n\r\n\t}\r\n\r\n}\r\n\r\nfinal class Fluent extends FluentBase<Fluent> {\r\n\r\n\t\/\/ nur eine instantiierbare Klasse, um die Funktion der Superklasse nutzbar zu machen.\r\n\r\n}\r\n\r\n\/\/ hat keine Typ-Beziehung zu Fluent\r\n\r\nfinal class ExtendedFluent extends FluentBase<ExtendedFluent> {\r\n\r\n\tpublic ExtendedFluent withExtendedValue(String caption, String value) {\r\n\r\n\t\treturn withValue(caption + \":\" + value + \"\\n\");\t\t\/\/ liefert durch die Superklasse den Typ ExtendedFluent zur\u00fcck\r\n\r\n\t}\r\n\r\n}\r\n\r\n<\/pre>\nGanz davon abgesehen, dass die Klassenhierarchie des StringBuilder<\/code> in der Java Runtime nicht in dieser Form vorliegt, h\u00e4tte ich auch\u00a0nicht die M\u00f6glichkeit gehabt, StringBuilder<\/code> als abstrakt zu erkl\u00e4ren und eine neue Ebene mit zwei neuen konkreten Subklassen einzuarbeiten. Au\u00dferdem ist damit immer noch keine Polymorphie zwischen StringBuilder<\/code> und CustomStringBuilder<\/code> m\u00f6glich.<\/p>\nLetztlich bleibt in diesem Fall nur die Delegation von einem CustomStringBuilder<\/code> zu einer internen StringBuilder<\/code>-Instanz ohne jede Typbeziehung als L\u00f6sung. Solange ich dieses Objekt nur lokal verwende und nicht an andere Akteure \u00fcbergebe, die einen StringBuilder<\/code> erwarten, kann ich wenigstens ein ununterbrochenes Fluent Interface genie\u00dfen.<\/p>\n