Fragen zu Orthogonalität und Kohärenz

DeepCopy

Ich habe jetzt schon mehrfach den Begriff Orthogonalität und Kohärenz gehört im Zusammenhang mit Designfragen, Klassen und Templates, ich kann mir darunter aber nichts vorstellen.

Meine Fragen:

Was genau bedeutet

* Orthogonalität
* Kohärenz

Und wofür braucht man dieses, bzw. was muss man beachten, und wo findet man Literatur zu diesen Themen ?

Dank im voraus
Grüssle DC!

pumuckl

Orthogonalität: Im Großen und Ganzen bedeutet es Unabhängigkeit. Für manche Teile einer Klasse (oder einer anderen Funktionelität) gibts manchmal verschiedene Lösungsmöglichkeiten. Oft kann man die Klasse so implementieren, dass so eine Lösungsmöglichkeit oder das dazugehörige Verhalten bei Bedarf ausgetauscht werden kann. Wenn es mehrere Teile gibt, die unabhängig voneinander ausgetauscht werden können, spricht man von Orthogonalität.
Viele objektorientierte Designpatterns ermöglichen Orthogonalität, wenn man sie richtig kombiniert. Ein anderer Stichpunkt zu dem Thema ist Policy Based Design.

kohärenz: kleines Beispiel: Basisklasse A hat eine virtuelle Funktion Foo() mit einem Rückgabetyp Bar*. Die abgeleitete Klasse B kann Foo() überschreiben, der Rückgabetyp müsste eigentlich wieder Bar* sein. Es kann aber auch Bar2* sein, wenn Bar2 von Bar abgeleitet ist. Sprich, B::Foo() kann einen eingeschränkteren Rückgabetyp haben als A::Foo(). Das Überschreiben mit einem eingeschränkteren Rückgabetyp nennt sich kohärentes Überschreiben. Häufiges Beispiel:

class Base
{
  virtual Base* clone();
};

class Derived
{
  /* virtual Base* clone(); */
  virtual Derived* clone();
};

Oh, sorry DC. Ich meinte Kohäsion und nicht Kohärenz :). Jetzt habe ich dich auf die falsche Fährte gelockt und keiner hat mich im anderen Thread korrigiert.

Das was pumuckl als Kohärenz bezeichnet kannte ich nur als Kovarianz, dass es auch Kohärenz genannt wird wusste ich gar nicht.
Ich behaupte mal das Kohäsion und Orthogonalität das selbe sind.

Infos zu Kohäsion findest du in Exceptional C++ und wikipedia (http://de.wikipedia.org/wiki/Koh%C3%A4sion_(Informatik)).
Orthogonalität wirds zB in "Der pragmatische Programmierer" genannt.

Beides assoziere ich sehr start mit "wohldefinierte Einheit", genauso wie es im wiki auch genannt wird.

Edit: English wiki auch gut -> http://en.wikipedia.org/wiki/Cohesion_(computer_science)

pumuckl

KasF schrieb:

Das was pumuckl als Kohärenz bezeichnet kannte ich nur als Kovarianz, dass es auch Kohärenz genannt wird wusste ich gar nicht.

Jaaaa, stell mich bloß *g* Mein Fehler, bringe das immer durcheinander...

DeepCopy

Also ich erlaube mir das mal zusammenzufassen:

Wir haben jetzt vier Fachbegriffe:

Kohäsion       : "Don't Repeat Yourself" - Funktion, Klasse erfüllt genau eine Aufgabe (Ok)
Kovarianz      : Ist mir bekannt unter dem Begriff: "covariant return tpye" in der Vererbung (Ok)
Kohärenz       : ??? 
Orthogonalität : Ist das Selbe wie Kohäsion (???) lt. KasF -ODER- Wenn es mehrere Teile gibt, die 
                 unabhängig voneinander ausgetauscht werden können, spricht man von 
                 Orthogonalität == Policy Based Design. (???) lt. pumuckl

Schonmal Danke für eure weiteren Antworten
Grüssle DC!

DeepCopy

Ich möchte eigentlich doch genau wissen was Orthogonalität und Kohärenz sind, bis jetzt habe darauf keine oder widersprüchliche Antworten erhalten, erstaulich auch das unsere Experten hier im Forum zwar gerne die Begriffe benutzen aber anscheinend die exakte Definition nicht preisgeben wollen?

Auch scheint die Begriffe Orthogonalität und Kohärenz ein recht neue Wortschöpfung zu sein, ich finde keine entsprechenden Archiveinträge vor 2008 (Orthogonalität) bzw. 2006 (Kohärenz).

Ein paar Beispiele Orthogonalität:

Aus einem anderen Thread: Binärbaum +STL oder nicht

camper schrieb:

Hier offenbart sich eine Schwäche (mangelnde Orthogonalität) bei der Spezifikation von Templatparametern: während ein typename X jeden beliebigen Typ umfasst, gibt es keine Möglichkeit, einen non-type Templateparameter beliebigen Typs zu spezifizieren (den tatsächlichen Typ könnte man dann durch partielle Spezialisierung oder decltype bestimmen). Vermutlich stehe ich mit dieser Ansicht aber ziemlich allein da, jedenfalls ist mir kein enstrepechender Vorschlag für C++0x bekannt.

Und hier: Frage bezüglich der Deallokierung/Ownership von Elementen
Auszug...

_dv schrieb:

Mit anderen Worten, die Ownership-Frage auslagern in eine eigene Struktur (in dem Fall "world"). Darüber habe ich schon nachgedacht. Was mir daran gefällt ist die Orthogonalität; Scene, Item etc. müssen nix mehr über Ownership wissen. Es besteht aber die Möglichkeit eines Memoryleaks, wenn man vergisst, nach dem Erzeugen des Items dieses der World-Klasse hinzuzufügen. Das klingt für mich wie ein Fehler, der häufig vorkommen könnte. Darüberhinaus musst du überall die World-Instanz durchreichen, und es wirkt etwas seltsam, dass du manche Sachen zusätzlich auch der World-Instanz hinzufügst und manche nicht.

Auch nicht schlecht: Function-Pointer mit Referenz-Operator (Stroustrup)
Auszug...

camper schrieb:

Der Referenzdeklarator deklariert eine Referenz. Da der Rest der Deklaration eine Funktion spezifiziert, ist rifii somit eine Referenz auf eine Funktion. Solchen Referenzen sind im Prinzip nichts Besonderes, allerdings werden sie praktisch selten verwendet, da ihre Rolle durch Funktionszeiger in aller Regel genauso gut erfüllt werden kann (auch syntaktisch, wegen der impliziten Konvertierung von lvalue-Funktionsausdrücken in Funktionspointer und der Möglichkeit, den Funktionsaufrufoperator direkt mit Funktionszeigern zu verwenden). Das ist also ein Feature, das größtenteils der Orthogonalität dient. Benutze solche Referenzen so wie andere Referenzen auch.
Beachte, dass es keine Referenzen auf Member gibt: zwar gibt es Zeiger auf Member aber das sind auch keine Zeiger (der Begriff ist einfach nicht besonders gut gelungen).

Ein nur ein Beispiel Kohärenz:

Von hier: delete this im Konstruktor?
Auszug...

camper schrieb:

ohne es nochmal nachgelesen haben - es könnte möglicherweise definiertes verhalten haben, wenn der destruktor trivial ist. ein objekt lebt, nachdem der konstuktor vollständig ausgeführt wurde - der konstruktor selbst stellt ja erst die kohärenz zwischen seinen membern her (die in der initialisierungsliste fertig werden) - und diese invarianten machen aus der ansammlung von member erst ein ganzes objekt (nach meinem verständnis). für diese interpretation spricht ja gerade auch, dass der dtor im fall einer exception eben nicht ausgeführt wird. was passiert bei delete this: ...

Ich würde mich freuen wenn diese Unklarheiten eindeutig geklärt werden könnten.
G-DC!

camper

Kohärenz wird dir in der Physik öfter über den Weg laufen, in dem Zitat - wo hast du das ausgekramt? - ist es nur als Synonym zu Konsistenz zu verstehen.

Orthogonalität ist kein neuer Begriff, auch nicht im Zusammenhang mit C++. Ich erlaube mir mal Stroustrup zu zitiern

Design and Evolution of C++ schrieb:

3.13.
...
There is a great temptation for a language designer to provide features and services where the alternative is for users to use a workaround. The screams when an addition is rejected are usually far louder than the complaints that "yet another useless feature has been added." This is also a serious problem for standards committees (§6.4). The worst variant of this argument is the cult of orthogonality. Many people feel that if the language would be more orthogonal if it provided a feature, then that is a conclusive argument for accepting that feature. I agree that orthogonality is a good thing in principle, but note that it also carries costs. Usually, despite all good intentions about orthogonality, the definition of a combination of features does require extra work on the manual and the tutorial material. Most often, implementation of combinations prescribed by the ideal of orthogonality is harder than people realize. In the case of C++, I always considered the run-time and space cost of orthogonality for people who did not use a combination. If cost couldn't at least in principle be made zero, I was most reluctant to admit the feature - however orthogonal. Thus orthogonality is a secondary principle - after the primary but subjective concerns of utility and efficiency.

...
4.2
...
Provide comprehensive support for each supported style: C++ must grow to meet the needs of serious developers. Simplicity is essential, but it is considered relative to the complexity of the project in which C++ is used. Maintainability and run-time performance of systems written in C++ is considered more important than keeping the language definition short. This implies a relatively large language.
It also implies - as experience showed - that many hybrid styles of programming must be supported. People don't just write classes that fit a narrowly defined abstract data type or object-oriented style; they also - often for perfectly good reasons - write classes that take on aspects of both. They also write programs in which different parts use different styles to match needs and taste.
Consequently, features must be designed to be used in combination. This leads to a degree of orthogonality in the design of C++. The opportunity for "unusual" uses is an important source of flexibility and has repeatedly allowed C++ to be used in areas where a more restricted and narrowly focused language would have failed. For example, the C++ rules for access protection, name lookup, virtual/non-virtual binding, and the type are orthogonal. This opens the possibility for a variety of techniques relying on information hiding and derived classes. Some who would prefer to see only a few narrowly defined styles of programming supported deem this "hackery." On the other hand, orthogonality is not a first-order principle; it is applied wherever it doesn't conflict with one of the rules and whenever it provides some benefit without complicating implementations.

Gemeint ist ist hier also, dass es möglich ist, verschiedene Techniken oder Sprachfeatures beliebig und unabhängig von einander zu kombinieren.
Vererbung und Templates erfüllen diese Bedingung beispielsweise sehr gut, durch Kombination kann man u.a. policy-basierte Klassen konstruieren.

Ein Gegenbeispiel wäre wie oben zitiert das Verhältnis zwischen partieller Spezialiserung von Templates und der möglichen Arten von Templateparametern. Während Templateparameter selbst bestimmte skalare Werte oder Typen oder Templates sein können, ist partielle Spezialisierung nur im Fall von Typparametern möglich.

P.S. Das Buch hat einen Index - falls die unsinnige Frage aufkommen sollte, ob ich es auswendig kenne.

Dasd

Vllt. noch zur Motivation für den Begriff "Orthogonalität" an sich:

http://en.wikipedia.org/wiki/Orthogonality#Computer_science schrieb:

For example, a car has orthogonal components and controls (e.g. accelerating the vehicle does not influence anything else but the components involved exclusively with the acceleration function). On the other hand, a non-orthogonal design might have its steering influence its braking (e.g. electronic stability control), or its speed tweak its suspension.[1] Consequently, this usage is seen to be derived from the use of orthogonal in mathematics: One may project a vector onto a subspace by projecting it onto each member of a set of basis vectors separately and adding the projections if and only if the basis vectors are mutually orthogonal.

Man kann also sagen, in einem 2-dimensionalen Koordinatensystem kannst du die x-Koordinate nur dann unabänhgig von der y-Koordinate verändern, wenn die Koordinatenachsen senkrecht (=orthogonal) zueinander stehen.

DeepCopy schrieb:

Ich möchte eigentlich doch genau wissen was Orthogonalität und Kohärenz sind, bis jetzt habe darauf keine oder widersprüchliche Antworten erhalten, erstaulich auch das unsere Experten hier im Forum zwar gerne die Begriffe benutzen aber anscheinend die exakte Definition nicht preisgeben wollen?

Heyhey, mal nicht so voreilig

Ich glaube zur Orthogonalität wurde schon alles gesagt. Zur Kohäsion noch:
Ganz so gleich sind beide wohl doch nicht. Ich würde sagen das Kohäsion die Orthogonalität unterstützt. Wenn "Teile" nicht kohäsiv (:)) wären, dann könnte man sie nicht so einfach austauschen um Orthogonal zu sein.

DeepCopy

Danke für die Antworten und Klärung

Ich fasse zusammen:

Kohäsion       : "Don't Repeat Yourself" - Funktion, Klasse erfüllt genau eine Aufgabe (Ok)
Kovarianz      : Ist mir bekannt unter dem Begriff: "covariant return tpye" in der Vererbung (Ok)
Kohärenz       : Synonym für Konsistenz (Ok)
Orthogonalität : Wenn es mehrere Teile gibt, die unabhängig voneinander ausgetauscht werden können, spricht man von
                 Orthogonalität (auch Policy Based Design). Zitat Stroustrup: "provide features and services where 
                 the alternative is for users to use a workaround..." "Thus orthogonality is a secondary 
                 principle - after the primary but subjective concerns of utility and efficiency."  (Ok)

Thx
G-DC!

otze

Zum dritten.

Policy based Design ist eine extreme Anwendung dieses Prinzips. Die beiden Sachen sind aber nicht gleichzusetzen