Wann kommt neues OpenGL?
-
Warum dürfen Methoden in OO keine Parameter haben?
Keine Ahnung, dies hat KXII als Gegenargument aus dem Hut gezaubert und ich hab keinen blassen Schimmer, woher er das hat. Selbstverständlich dürfen Methoden Parameter besitzen *kopfschüttel*Eigenschaften/Verhalten versus Variablen/Funktionen
Nehmen wir ein real existierendes Objekt - einen Stuhl. Ein Stuhl hat gewisse Eigenschaften (Material, Sitzhöhe, Gewicht etc.). Nehmen wir weiterhin an, ich schreibe eine Anwendung in der ich besagte Objekte in irgend einer Form verwalten will/muss/soll. An irgendeiner Stelle im Programm benötige ich die Information, ob sich besagter Stuhl im Wohnzimmer befindet. Jetzt gibt es zwei Möglichkeiten.
Programmierer A, der eine Klasse/Objekt nur als Sammelsurium von Variablen und Methoden versteht, wird keine Probleme haben einfach der Klasse ne neue Variable 'm_fStehtImWohnzimmer' zu spendieren. Er braucht die Information an dieser Stelle, es ist bequem, und außerdem hat er schon x Jahre Erfahrung und braucht sich deswegen keinerlei Gedanken zu machen.
Programmierer B, der eine Klasse/Objekt eben nicht nur als Sammelsurium von Variablen/Methoden versteht, wird sich überlegen, ob 'StehtImWohnzimmer' wirklich eine Eigenschaft von 'Stuhl' ist und realativ schnell feststellen. Nöö.
Also hat diese Variable auch nix in der Klasse 'CStuhl' zu suchen. Ergo muss er sich eine andere Lösung einfallen lassen. Vielleicht bracht er 20min. länger als Programmierer A (der die Zeit schonmal dazu genutzt hat, weitere Variablen in die Klasse zu integrieren wie 'm_fStehtImFlur', 'm_fStehtImSchlafzimmer', 'm_fStehtAufDerTerrasse').
Falls Programmierer B dieses Vorgehen konsequent einhält, und sich bei jeder Erweiterung der Klasse 'CStuhl' fragt, ob es sich wirklich um eine Eigenschaft bzw. um ein Verhalten eines Stuhles handelt, wird der erzeugte Code garantiert rubuster gegen Änderungen sein (spätestens, wenn Programmierer A mitbekommt, das ein Mehrfamilienhaus auch mehrere Wohnzimmer hat, werden bei ihm die Panikpickel sprießen). Weiterhin erhöht sich die reale Chance, das seine Klasse auch in anderen Projekten Verwendung finden kann, da die Klasse nicht mit anwendungsspezifischen Müll vollgestopft ist.
In diesem Zusammenhang ist vielleicht der Satz "Objektorientiertheit hat aber nix mit der sinnvollen Gruppierung von Funktionen und Variablen zu tun" besser zu verstehen. Wenn ich Variablen und Funktionen in mehr oder weniger sinnvollen Gruppen zusammenfasse, dann führe ich eine funktionale Aufgabenteilung durch. In der OOP (so wie ich sie verstehe) geht es aber nicht um "Aufgabenteilung in Funktionen" sondern um die Organisation von Verantwortungen. Daher ist ein Objekt mehr als nur eine Zusammenfassung von Variablen und Funktionen.In meiner täglichen Arbeit sehe ich einfach, das es viel zu viele Programmierer der Kategorie A gibt, die ohne auch nur 5 sec. zu überlegen eine Klasse erweitern, und deren Klassenhierarchie (falls man das so nennen kann) bei der kleinsten Anforderungsänderung in sich zusammen fallen.
Was mit realen Objekten wie einem Stuhl funktioniert, das funktioniert übrigens genauso mit abstrakten Objekten.
Eine weitere Sache, die mir immer wieder negativ auffällt (und nicht wirklich dem OO-Gedanken entspricht) ist die Tendenz, Objekte von Außen zu manipulieren, anstatt die Objekte selbst agieren zu lassen (Verhalten versus Methode). Aus diesem Grunde benötigt die Simulation von Helium auch keine set_position()-Methode, da die Planeten eben nicht von Außen durch eine übergeordnete Instanz (Manager) manipuliert werden sondern selber agieren. Hierzu ist es logischerweise notwendig, das Objekte miteinander kommunizieren (was mittels Methoden, die selbstverständlich auch Parameter besitzen können, erfolgt). Randbemerkung: und falls es doch besagte Methode geben sollte, ist das kein Indiz dafür, das er nicht objektorientiert programmieren würde, nur um etwaige Argumentationen der Kategorie "Methoden dürfen keine Parameter besitzen" vorzubeugen.Auch wenn es zweifelhaft bis kritisch ist, OO an einer einzigen fiktiven Programmzeile zu messen, die vollkommen alleine ohne jeden Kontext da steht, hol ich unseren alten Bekannten 'held' wieder aus der Schublade.
held_leben = 0; // autsch
held.leben = 0; // Objekt wird von Außen manipuliert und riecht für mich nach funktionaler Aufgabenteilung (was eher das genaue Gegenteil von OO ist), soll heißen: es gibt eine übergeordnete Instanz, die in diesem Falle über Leben und Tod entscheidet. Wir haben einen Manager (besagte Instanz) und einen Gemanagten (unseren Helden). Auch nicht viel besser.
held.strib(); // Es wird schon besser, nur zu mittelhohen Luftsprüngen mit pausenlosem Juhu-Geschrei reicht es noch nicht.
held.TakeDamage(10); // Eine Instanz (ein anderes Objekt) kommuniziert mit unserem Helden und sagt ihm 'ich füge dir Schaden zu'. Wie unser Held sich daraufhin verhält ist seine Sache (unter Umständen fällt er einfach um und ist Tod). Der grosse Unterschied zu den oberen Zeilen ist, das es keine übergeordnete Instanz gibt, welche unseren Helden (direkt) manipuliert. Unser Held agiert bzw. reagiert selber und wird nicht gemanagt.Nachsatz
Da KXII seine Biographie zum besten gegeben hat, kann ich mir folgendes einfach nicht verkneifen (man möge mir bitte verzeihen): Ich bin 37 Jahre alt, habe mit 16 angefangen zu Programmieren. Zuerst in Basic und relativ schnell dann in C. Während meiner Ausbildung habe ich einen klitzekleinen Abstecher zu Pascal, COBOL und Assembler gemacht und bin vor 11 Jahren bei C++ hängen geblieben. Aufgrund 21-jähriger Programmiererfahrung (davon 15 Jahre beruflich) kann ich ohne Bedenken und mit viel Selbstvertrauen sagen, dass ich soweit fortgeschritten bin, um zu erkennen, das meine Lernphase nie abgeschlossen sein wird und keine angehäufte Erkenntnis so stark manifestiert ist, das sie nicht in Frage gestellt werden könnte, egal durch was (Artikel in Fachzeitschriften, Bücher oder im Netz) oder durch wen (John Carmack oder einem 16-jährigen Member hier im Forum). Und genau das finde ich so faszinierend.
-
man, du hast mir gerade mein bewustsein erweitert! danke! ich habe grade deine theorie durchgerechnet, und du hast tatsächlich recht! nicht zu fassen! alles macht plötzlich einen sinn. wie konnte ich nur so blind sein. es liegt doch auf der hand. was du gesagt hast ist nichts als die wahrheit. immer war es richtig. und ich idiot habe es nicht gesehen. ich hoffe du kannst mir verzeihen.
also nochmals:
ENTSCHULDIGE BITTE! SORRY, FÜR ALLES WAS ICH DIR ANGETAN HABE! ES WIRD NICHT WIEDER VORKOMMEN!
-
-
Meiner besaß zwar auch ein get_position(), aber kein set_position(), was, wenn ich dich richtig einschätze, ür dich völlig absurd ist. Aber man kann einen Planeten nicht einfach durch die gegend beamen (selbst bei Star Trek hat das noch keiner geschaft). set_position() kann somit niemals eine eigenschaft von Planet sein.
Und siehe da trotzdem funktioniert meine Simulation perfekt. Falls du jetzt denkst, es gäbe etwas vergleichbares zu set_position() nur unter anderem Namen, dann irrst du dich.@helium, killing me softly
Heisst das das sich die Planeten immer nur die Information mittels getFunktionen von anderen Planeten holen (z.b. von der Sonne um die die Planeten kreisen) und daraus ihre eigene Position selber bestimmen/berechnen?Kann nicht z.b. ein schwarzes Loch die Funktion planet1.setPosition() aufrufen? Schliesslich beinflusst ja das schwarze Loch den Planeten und zieht den Planeten zu sich her und verschluckt ihn dann schlussendlich? Die Verantwortung liegt dann beim Loch! Das Loch wird aktiv und sagt ich verschlucke jetzt den Planeten und ziehe in zu mir her sprich ich verändere seine Position.
Nachtrag:
Hmm...ah ich glaub ihr meint das soSchwarzesLoch{ private: int m_distance; void lookForPlanets(...){ if(planet1.getPosition <= m_distance) planet1.getInfluenced(vector direction); // also das schwarze loch setzt nicht die position des planeten, sondern // sagt nur das es den planeten zu sich herzieht. ob der planet dann auch // zum loch kommt bestimmt er selber. der planet könnte sich ja dagegen wehren // (eher unwahrscheinlich *g*). } }
[ Dieser Beitrag wurde am 01.07.2003 um 02:01 Uhr von cpt.oneeye editiert. ]
-
Ich weis zwar nicht wie Helium das gemacht hat, aber ich würde es folgendermaßen realisieren:
Frage: ist es wirklich die Aufgabe eines Schwarzen Loches, einem Planeten zu sagen, wie er sich zu verhalten hat? Antwort: nein, es liegt klar in der Verantwortung des Planeten. Der Planet kann ohne Probleme die Position und deren Masse der anderen Himmelskörper abfragen und daraus die auf ihn wirkende Gravitation und hiermit seine Flugbahn berechnen (ein Schwarzes Loch ist ja auch nur ein Himmelskörper, nur mit ner verdammt großen Masse).Das Beispiel ist übrigens gut. Nehmen wir an, die Simulation ist fertig programmiert und zum Schluss kommen wir auf die Idee, wir könnten ja auch Raumschiffe in unserem virtuellen Weltall fliegen lassen. Welcher Änderungsaufwand ist hierfür notwendig? Bei meiner Lösung muss die Simulation nicht angepasst werden, das einzige was ich brauche ist eine neue Klasse CRaumschiff. Würden die Himmelskörper aber wie in deiner 2. Variante von Außen manipuliert werden, dürfte man alle Klassen durchgehen und entsprechend ändern.
Und damit hätten wir auch gleich den großen Vorteil einer sauberen OO-Programmierung demonstriert - sie ist relativ unempfindlich gegenüber nachträglichen Änderungen/Erweiterungen.
[ Dieser Beitrag wurde am 01.07.2003 um 13:34 Uhr von Killing me softly editiert. ]
-
[QB]Und damit hätten wir auch gleich den großen Vorteil einer sauberen OO-Programmierung demonstriert - sie ist relativ unempfindlich gegenüber nachträglichen Änderungen/Erweiterungen.[QB]
Das ist doch TRIVIAL!
Das trifft genauso für strukturierte Programme zu!
-
@Killing me softly
freut mich zu wissen wie alt du bist und wieviel erfahrung du hast. ich finde das verbessert die kommunikation, weil man weiß mit wem man es zu tun hat.
ABER:
deine extrem lange ausführung mit den drei überschriften, zeigt, daß du das problem absolut nicht kappierst. deine argumente sind lediglich NICHTS ANDERES als UNTERSTELLUNGEN und ANNAHMEN, und haben mit der definition allgemeiner OOP oder genauer gesagt, mit dem beweis, daß das was ich sage falsch ist, ASBOLUT NICHTS ZU TUN. um nur eines deiner bescheuerten beispiele zu nennen:
ich muss hoffentlch nicht beweisen, das "programmierer A" ein programmierer nach meiner definition ist. ich glaube das geht deutich aus dem text hervor.
**Programmierer A, der eine Klasse/Objekt nur als Sammelsurium von Variablen und Methoden versteht, wird keine Probleme haben einfach der Klasse ne neue Variable 'm_fStehtImWohnzimmer' zu spendieren. Er braucht die Information an dieser Stelle, es ist bequem, und außerdem hat er schon x Jahre Erfahrung und braucht sich deswegen keinerlei Gedanken zu machen.
Programmierer B, der eine Klasse/Objekt eben nicht nur als Sammelsurium von Variablen/Methoden versteht, wird sich überlegen, ob 'StehtImWohnzimmer' wirklich eine Eigenschaft von 'Stuhl' ist und realativ schnell feststellen. Nöö.
Also hat diese Variable auch nix in der Klasse 'CStuhl' zu suchen. Ergo muss er sich eine andere Lösung einfallen lassen. Vielleicht bracht er 20min. länger als Programmierer A (der die Zeit schonmal dazu genutzt hat, weitere Variablen in die Klasse zu integrieren wie 'm_fStehtImFlur', 'm_fStehtImSchlafzimmer', 'm_fStehtAufDerTerrasse').
**alles unterstellungen; entspringen aus deiner programmirerefantasie, so wie du das programmieren siehst, es hat aber nichts mit der realität zu tun und auch nichts mit einer SINNVOLLEN und AKZEPTABLEN darstellung, die einen erkennen lässt, "ach ja, da ist ja wirklich was dran. meine darstelung sollte ich nochmal überdenken."
woher nimmst du dir die freiheit einfach sagen, das aus meiner argumentation automatisch auch deine oben aufgeführten darstellungen folgern? nur weil bei meiner definition alle darstellungsmöglichkeiten von methoden die objektorientierte programmierung nicht ausschliessen, heisst das doch noch lange nicht, das meine objekte automatisch schlecht designt sind, und ich ihnen deshalb automatisch funktionen verpasse, die gar nicht für sie bestimmt sind und die nichts mit dem objekt zu tun haben! warum sollte ich einem stuhl methoden verpassen, die einen kuchen backen oder ein auto waschen oder jemanden das essen bringen? warum sollte das so sein? HÄ? DENK darüber nochmal nach! ausserdem hat das eine mit dem anderen nichts zu tun.
hier werden die unterstellungen ganz deutlich:
...Er braucht die Information an dieser Stelle, es ist bequem, und außerdem hat er schon x Jahre Erfahrung und braucht sich deswegen keinerlei Gedanken zu machen.
*HAHAHAHAHA*
warum BRAUCHT er diese informationen an dieser stelle, wenn er nach meiner definition programmiert? er braucht sie NICHT!
warum ist es nur dann bequem wenn er nach meiner definition programmiert? es ist IMMER bequem müll zu programmieren!
warum braucht er sich keine gedanken darüber zu machen, wenn er nach meiner definition programmiert? man muss sich immer gedanken über das machen, was mann programmiert!
alle drei teilsätze sind unterstellungen und helfen dir nur, anderen, die den text nicht genau gelesen haben, den nachfolgenden text glaubhafter anzuerkennen, weil ja vorher was da gestanden hat, was offensichtlich falsch war. *tzzzz*
lebensalter hin, lebensalter her, deine programmiererfahrung hin oder her, das spielt keine rolle, wenn du nicht erkennst worum es eigentlch geht. mich wundert es, das du so unlogische ausführungen bringst. möchtest du absichtlich unglaubhaft sein? das kann ich mir nicht vorstellen.
du kannst bestimmt sehr gut programmieren und ich würde das auch niemals bestreiten. deine argumentationsweise in DIESEM POSTING ist aber extrem lächerlich! ich muss es so darstellen, weil ich wirklich nur noch darüber lachen kann, wie du und helium versucht zu argumentieren.
[ Dieser Beitrag wurde am 01.07.2003 um 16:18 Uhr von KXII editiert. ]
-
halt die Klappe, du unerfahrenes kiddie.
-
das mache ich auch, wenn mich jemand versucht zu ver*****en.
"auf die fresse kloppen" ist was für proleten.
[ Dieser Beitrag wurde am 01.07.2003 um 16:15 Uhr von KXII editiert. ]
-
"...kann ich ohne Bedenken und mit viel Selbstvertrauen sagen, dass ich soweit fortgeschritten bin, um zu erkennen, das meine Lernphase nie abgeschlossen sein wird und keine angehäufte Erkenntnis so stark manifestiert ist, das sie nicht in Frage gestellt werden könnte, egal durch was ..."
1.) lernphasen sind nie abgeschlossen. das ist trivial. jeder der arbeitet weiss das.
2.) man kann alles in frage stellen. dafür gibt es aber geeignete psychologische begriffe und es ist kein normales verhalten. ich habe mindestens 100 erkenntnisse, die ich als manifestiert betrachte. schade das du keine hast.
-
Original erstellt von <Giftzwerg>:
ich habe mindestens 100 erkenntnisse, die ich als manifestiert betrachte. schade das du keine hast.Welche denn zum Beispiel?
-
Original erstellt von KXII:
...und ich kann ohne bedenken und mit viel selbstvertrauen sagen, dass ich soweit fortgeschritten bin, dass ich keine bücher mehr brauche, die mir die grundlagen des programmierens erklären!...Original erstellt von KMS:
...kann ich ohne Bedenken und mit viel Selbstvertrauen sagen, dass ich soweit fortgeschritten bin, um zu erkennen, das meine Lernphase nie abgeschlossen sein wird und...Vielleicht verstehst du jetzt den kleinen Seitenhieb in der Formulierung.
@KXII: Antwort kommt heute Abend, hab' gerade nicht die Zeit dazu.
-
lass gut sein. meine zeit ist zu kostbar.
-
@Sgt. Nukem: Dir war unklar, was es mit den Datei und Verzeichnissen im Zusamenhang mit Klassen auf sich hat. Dazu musst du wissen, das Gregor Java programmiert. Und da spielt die Aufteilung in Verzeichnisse, etc. eine Rolle. Es ist also etwas Javaspezifisches. Das nur zum Verständlnis.
"Falsch" isset schonmal gar nicht. Höchstens nicht objektorientiert...
Entschuldige meine ungenause Ausdrucksweise ich meinte Falsch im Sinne der Objektorientierung.
warum sollte ich einem stuhl methoden verpassen, die einen kuchen backen oder ein auto waschen oder jemanden das essen bringen? warum sollte das so sein?
Wie kommst du darauf? Das ist völlig absurdes Zeug. es kann doch durchaus von Interesse sein, wo der Stuhl steht und darum ging es.
1.) lernphasen sind nie abgeschlossen. das ist trivial. jeder der arbeitet weiss das.
Das heißt ich lerne immernoch zu gehen. Ich dachte das könne ich bereits.
@KXII: Bevor ich jetzt irgendwelche Mutmaßungen darüber anstelle, wie du programmierst, könntest du nicht einfach zu Demonstrationszwecken eine deiner Klassenhirachien zeigen. Am besten wäre ein einfaches UML-Diagram.
Meine und Killing me softlys vorgehensweise kennst du ja nun.
BTW, ich habe auchmal ähnliche Ansichten vertreten wie du. deswegen kenne ich beide Seiten. Du hast wie du es nennen würdest "meine Art der OOP" hingegen noch nicht probiert. Vielleicht solltest du das, bevor du ein Urteil fällst, mal tun.
-
"Das heißt ich lerne immernoch zu gehen. Ich dachte das könne ich bereits."
JUPP!
du kannst es, musst es aber immer weiter lernen. wenn du 10 jahre nicht gehen würdest dann hättest du es verlernt. wenn du 10 jahre kein english mehr sprechen würdest, dann hättest du es verlernt. wenn du 10 jahre keinen kuchen mehr backen würdest, dann hättest du es verlernt.
aber es gibt auch noch eine andere perspektive:
man muss immer DAZULERNEN. gerade beim arbeiten ist das wichtig, damit man auch zukünftig leistung erbringen kann. aber auch beim gehen ist das wichtig. jemand der zwar gehen kann, aber noch nie einen marathon gelaufen ist, der wird schnell merken, das man da die richtige gangart braucht um schneller zu sein als andere. oder jemand der noch nie geklettert hat, der wird merken, das seine füße erst noch lernen müssen den richtigen tritt zu finden, um auf dem felsboden standhaft zu sein. oder wenn du auf dem mond spazieren gehen würdest, dann müsstest du das auch erst lernen.
[ Dieser Beitrag wurde am 02.07.2003 um 01:11 Uhr von KXII editiert. ]
-
ich numeriere meine klassenamane durch, das macht sie berechenbarer als mit asciizeichen. also:
class 1000
{
};oder
class 2000
{
};und hirachien gibt es bei mir erst gar nicht. alles ist public und dadurch gleichberechtigt. achja, zeiger und goto's sind hauptbestandteil meiner algorithmen.
[ Dieser Beitrag wurde am 01.07.2003 um 20:11 Uhr von KXII editiert. ]
-
Wo bleiben die kryptischen Makros, wilden Casts (wer braucht schon virtual?) und
inline asm?
Das muß man als guter Programmierer können, nein LIEBEN![ Dieser Beitrag wurde am 01.07.2003 um 22:18 Uhr von Kane editiert. ]
-
Original erstellt von KXII:
du kannst es, musst es aber immer weiter lernen. wenn du 10 jahre nicht gehen würdest dann hättest du es verlernt. wenn du 10 jahre kein english mehr sprechen würdest, dann hättest du es verlernt. wenn du 10 jahre keinen kuchen mehr backen würdest, dann hättest du es verlernt.Naja, gehen verlernt man nicht.
Einige Sachen sind ja auch angeboren...
@KillingMeSoftly: Sicher, daß Dir irgenein Artikel oder der John Deine manifestierte Meinung streitig machen können, daß 1 + 1 = 2 ist...?!?
-
Original erstellt von Sgt. Nukem:
**Naja, gehen verlernt man nicht.
**probiers doch mal und setz dich 10 jahre innen rollstuhl
-
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.