::::Das ist aber andere interessante Frage. Was Du beschreibst, ist eine Situation, in der ein Fehler nicht schnell genug von den Frameworkentwickler erkannt und beseitigt wird und die Benutzer sich an den Fehler so gewöhnen, dass sie sich auf das Verhalten sogar verlassen. Zuerst möchte ich sagen, dass ein Entwicklungsprozess, dar sowas zulässt, ein Problem hat und man sollte sich Gedanken machen, wie man den Prozess verbessert. ::::Nun aber zu dem schon existierenden Bug aus dem Feature wurde. Ich betrachet folgende Ansätze als sinnvoll: ::::Semantik neu definieren: Deklariere, dass der Bug ein Feature ist. Ändere die Dokumentation der Funktion, ändere die Tests, wenn der Name nicht passt, änderen den Namen (eventuell mit eine Deprecated-Überganszeit), wie oben besprochen. Dies geht natürlich nur dann, wenn der Bug/Feature konsistent verwendet werden kann. ::::oder ::::Korrigiere den Bug: Korrigiere den Bug. Die Benutzer haben Pech, sind aber selber Schuld, wenn sie ProgrammingByCoincidence? betreiben. Die Frameworkentwickler haben denen das Verhalten des Bugs nicht zugesichert, im Gegenteil. Wenn man zuläst, dass die entwickelte Software sich auf Bugs verlässt, wird sie irgendwann sowieso unter eigenem Gewicht kollabieren. Um den Benutzern des Framework das Leben zu erleichtern, immerhin sind die Frameworkleute mitverantwotlich, denn das FW hat zu lange den Bug "bereitgestellt", kann man eine Übergansphase mit Deprecations einplanen. Stell also die richtige Funktionalität zur Verfügung und mach die alte falsche Deprecated. Nachdem die SW, die das Framework verwendet, umgestellt wurde, beseitige den Bug endgültig. ::::In keinem Fall sollte man den Bug unbeachtet lassen, es sei den, man ist mit einer Slumarchitektur zufrieden --gR |
Konkretes Beispiel: In einer Klasse gibt es eine Methode, weshalb die Anwender des Framework sich schon oft beschwert haben. Diese Methode handelt nicht nur falsch, sondern vollständig entgegen aller Erwartung: sie tut das Gegenteil von dem, was sie vorgibt zu tun. Es steht zwar in der Doku drin, daß sie anders implementiert wurde, aber meint Ihr, folgender Code der SpracheJava wäre sinnig?
|
Nun sind sich alle Entwickler des Frameworks einig, daß man das so nicht lassen kann (ist ziemlich peinlich). Wie aber kann man das ändern? Vielleicht mögen einige hier ein wenig Erfahrung Kund tun? Mein Dank sei jenen gewiss! -- BerndSchiffer
|
-- gR
|
Ich weiß, dass folgendes nicht mit der von dir angestrebten Problemlösung zu tun hat, aber: warum verwendet ihr überhaupt solche IsParent- oder IsChild-Methoden und nicht statt
|
nicht einfach
|
die ohnehin zum Grundrepertoire des Objektes gehören muss? Auf den ersten Blick erscheint mir IsChild or IsParent als ein überflüssiges Interface. -- HelmutLeitner