K
Auf die existentiellen Fragen, ob 1+1 wirklich immer 2 ist und ob man die menschliche Fähigkeit auf zwei Beinen zu laufen durch kontinuierliche Konditionierung beliebig Perfektionieren kann, möchte ich an dieser Stelle nicht eingehen; das überlasse ich lieber anderen
@KXII: In meinem ersten Post habe ich u.a. von 'Eigenschaften' und 'Verhalten' gesprochen, ohne näher zu spezifizieren, was ich darunter verstehe bzw. wieso ich diese Begriffe der üblichen Benennung (Variablen/Methoden) vorziehe. Dies hat (zu Recht) dazu geführt, das meine Ausführungen teilweise falsch verstanden worden sind. Der Abschnitt war also primär dazu gedacht, besagte Begrifflichkeiten bzw. Aussagen zu klären (deswegen auch die dicke fette Überschrift) und weniger, dich oder deine Programmierkunst in irgend einer Weise zu diskreditieren.
Randbemerkung: an dieser Stelle möchte ich auch betonen, das der Grad an objektorientiertem Design innerhalb eines Programmes kein Mass für die Qualität des Programmes oder den Fähigkeiten des Programmierers ist. Wenn man sich bspw. den Quake-Source ansieht, dann springt einem extrem Hardcore-C entgegen; nix was nur annähernd nach OO aussieht und ich glaube kaum, das es hier jemanden gibt, der Klein-John als Pfuscher betiteln würde. Wollte ich einfach mal loswerden.
Was mich an deiner Definition von OO stört (oder besser: mit der ich nicht Komform gehe) ist folgendes:
...bei OO geht es doch darum, funktionalität in sinnvolle gruppen zu packen...
...die FUNKTIONALITÄT die dahinter steckt ist in allen fällen die selbe...
Wenn du es so meinst, wie du es gesagt hast, dann sprichst du von einer "funktionalen Aufgabenteilung", dies entspricht aber dem klassich prozeduralen Paradigma. Die OO geht aber vom genauen Gegenteil aus, nämlich der "Aufgabenteilung nach Verantwortung". Da sich darunter kaum jemand im ersten Moment etwas vorstellen kann, hier mal ein Beispiel außerhalb der Programmierung.
Eine Firma besteht logischerweise aus verschiedenen Abteilungen. Bei der klassichen Aufteilung gibt es bsp. einen Einkauf, einen Vertrieb, eine Konstruktion, eine Produktion, einen Versand, eine Marketingabteilung u.s.w.. In diesem Falle spricht man von 'Funktionaler Organisation' d.h. jede Abteilung hat eine bestimmte Funktion (logisch). Der Einkauf hat die Funktion, Teile zu beschaffen; die Produktion hat die Funktion, aus den Einzelteilen das fertige Produkt zu bauen; das Marketing hat die Funktion, Werbung zu machen und so weiter.
Man kann seine Firma aber auch komplett anders organisieren. Eine Möglichkeit ist die Abteilungen nach Produktgruppen zu unterteilen (divisionale Organisation), d.h. die einzelnen Abteilungen sind für ein bestimmtes Produkt bzw. Produktgruppe o.ä. verantwortlich. In so einer Abteilung tummeln sich dann Konstrukteure, Vertriebler, Werbefritzen u.s.w.. Bei einer solchen Organisation ist z.B. die Gefahr, das die Konstruktion was "erfindet" was kein Mensch gebrauchen kann und der Vertrieb deswegen die Sachen nicht unters Volk bringt bzw. der Vertrieb den Kunden das Blaue vom Himmel verspricht, das so nie und nimmer produziert werden kann (und wenn doch, dann nicht für den Preis), nicht so stark gegeben (dafür gibt's andere Probleme).
Es gibt also mehrere Möglichkeiten ein großes System zu organisieren. Die geläufigste ist nach Funktionen; eine andere währe z.B. nach Verantwortungsbereichen.
Zurück zur Programmierung: Auch bei der Programmierung ist es notwendig eine Organisation aufzubauen d.h. das System in überschaubare Bereiche aufzuteilen. Auch hier kann die Teilung nach funktionalen Gesichtspunkten erfolgen (klassisch prozedurales Paradigma). Die OOP geht aber einen anderen Weg. Hier geht es (ich wiederhole mich) um die Organisation von Verantwortlichkeiten. Die Funktionalität des daraus aufgebauten Programmes entsteht so gesehen erst im zweiten Schritt, nämlich durch das Zusammenspiel der Objekte und nicht dadurch, das die Funktionalität selbst in Gruppen zusammengefasst, ne Klammer drumrum gesetzt und class davor geschrieben wird.
