Bashar schrieb:
Aus dem ersten Satz folgt nicht der zweite. Das Produkt der quadrierten Sinusse der Elemente eines Vektors ergibt sich ja auch aus den Elementen. Nach der Argumentation müsste jede Funktion eine Eigenschaft sein. Diese Philosophie kann man zwar vertreten, aber softwaretechnisch ergibt sich das Problem, dass man dann unendlich viele Methoden bräuchte. Es gibt sogar schon unendlich viele Normen.
Die Schlussfolgerung ist, dass es bei der Frage, ob etwas eine Eigenschaft ist, nicht darauf ankommt, ob man sie aus den Elementen berechnen kann. Ich halte es da mit Stepanov und präferiere minimale Interfaces. Eine Klasse sollte nur diejenigen Funktionen als Member anbieten, die sich nicht oder zumindest nicht performant mithilfe der anderen öffentlichen Memberfunktionen implementieren lassen. Ein schönes Beispiel für diese Denkweise ist ein alter Artikel von Herb Sutter, Monoliths Unstrung, in dem er die std::string-Klasse kritisiert.
Ich muss zugeben, der Mann hat gute Argumente. Ich habe mich selber schon öfters über den Mangel an sequenzorientierten Algorithmen in der STL außerhalb von std::string geärgert. Und gerade eben habe ich (bevor ich dies las) selber mein Projekt auf eine Weise umgebaut, die hier beschrieben wird, einfach weil es mir selbstständig als besseres Design vorkam War ein ganz ähnlicher Fall, wo ich überlegt habe, ob eine Klasse wirklich den Algorithmus auf ihren Daten selber zur Verfügung stellen muss. Komisch, dass ich dies nicht auf den mathematischen Vektor übertragen habe. Denkblockade wegen der Wärme vermutlich ).
