API-Programmierer vers. Effizienz-Programmierer?

Heute eine interessante Unterhaltung mit einem Programmierer gehabt, der wissen wollte, ob und inwieweit man Maps via WebServices übergibt und ein Objekt zurückerhält (dazu vielleicht ein andermal mehr).

Die sich daraus entspinnende Diskussion ergab, dass geplant war, eine Schnittstelle, die auch via Corba-IDL an externe Kunden für deren Software herausgegeben wurde, dramatisch zu ändern: Anstelle der vorhandenen statischen Methoden, die im "Apache-Commons-Stil" viele Komfortmethoden bereitstellten, um bestimmte Werte zu berechnen, sollte ein einziges generisches Interface angeboten werden.

Dieses Interface sähe so aus, dass über eine generische Klasse für alle Produktlinien eine Klasse instantiiert werden soll, der im Konstruktor eine Map übergeben wird, der man alle Werte für den jeweils gewünschten "Methodenersatz" in einer Map übergeben soll. (Ggf. soll aber doch auch eine entsprechende statische Methode mit einer Map als einzigem Parameter verwendet werden).

Rückgabewert sollte dann immer ein java.lang.Object sein, das unabhängig von Konstruktor/Methode (ich bevorzugte in diesem Fall ohnehin die statische Methode) entsprechend der Dokumentation erst in ein Map gecastet, dieses iteriert und die einzelnen Werte erneut gecastet werden sollen.

IMHO ist dieser "generische Ansatz" zwar u.U. geeignet, um interne Strukturen zu verbessern, aber nicht, um ein API zur Verfügung zu stellen:

• Entwickler können nicht mehr mit derselben Typsicherheit programmieren. Wurden – unter anderem – für dieses Problem nicht gerade Generics eingeführt? 😉
  Im Ernst – entsprechend Joshua Blochs Effective Java Programming (Advice 32) sollte man Strings nur verwenden, wo sie Sinn machen, nicht als beliebigen Ersatz von eindeutig verwendbaren Typen.
  Ducktpye mag ja angehen, aber ich finde nicht, dass die Aufgabe von Typsicherheit etwas mit Faulheit (Neal Ford) oder mit Unflexibilität zu tun hat. Typen ausdrücken zu können, hat etwas mit der Ausdrucksstärke der Sprache zu tun.
• Man kann keine Methodensignaturen mehr "deprecated" machen. Ich denke, dass die Verwendung von @deprecated für ein API bewusst eingesetzt werden soll. Die Lösung des erwähnten Programmierers lag darin, dass für den Fall, dass eine Berechnung eine geänderte "Signatur" erhält, eine entsprechende – durchaus aussagekräftige – Exception geworfen werden sollte. Damit gingen die "Segnungen" der Fehlermeldungen zur Compilezeit für Typprüfungen allerdings verloren.
• Manche Programmierer benutzen ja "Outlines" in ihrer IDE, manchmal ist auch nützlich, UML aus Methodensignaturen etc. zu extrahieren. Das Domain-Wissen, das hierüber *reflektiert* wird, ginge verloren und wäre günstigenfalls ausgelagert in Javadoc ausgelagert (an eine Annotations-basierte Lösung zu denken, wäre vielleicht ein wenig gewagt, ich habs deshalb gar nicht erwähnt).