Diskussion:Objekt und Klasse, Gegenstand und Begriff (CP)

Nützliche Fiktion in der Softwareentwicklung

"Ein Gegenstand, der einem Urteil unterzogen wird, ist nicht einfach die Realisierung eines Typs. Für die objekt-orientierte Analyse kann das besagte Fahrzeug als modelliertes Objekt einzig und allein der angegebenen Klasse angehören. Alle relevanten Charakteristika liegen auf ihrer Seite. Urteile finden hier keinen Anhaltspunkt. In ihnen geht es um die Abschätzung, inwieweit sich bestimmte Charakteristika von Gegenständen behaupten lassen. Dazu muß es experimentelle Handlungsfreiheit geben, ein Ausprobieren von Beschreibungen und Rückkoppelungen zwischen Subjekt und Prädikat. Die Ausprägung eines Attributes im Objekt kann hingegen keine Rückwirkung auf die Definition der Klasse haben." (H.H.)

Anbei der Versuch einer Reformulierung mehr unter der Perspektive der Softwareentwicklung und am Ende vielleicht einer Zusatzüberlegung: Die objekt-orientierte Analyse ist eine menschliche Praxis. Dagegen stehen die automatisierten Abläufe im Computer. Im ersten Fall sind Urteile unabdingbar, denn man muss rausfinden, was als Objekt welchen Typs modelliert wird. Der Designprozess erfordert und läuft parallel mit dem Erkenntnisprozess. Da sind wir auf der heuristischen Ebene. Verschiedene "Rahmungen" werden ausprobiert für ein "schönes Design". Darüber hat man auch in der Informatik geschrieben unter der Überschrift "Design Is a Sloppy Process (Even If it Produces a Tidy Result)":

"The finished software design should look well organized and clean, but the process used to develop the design isn't nearly as tidy as the end result.

Design is sloppy because you take many false steps and go down many blind alleys- you make a lot of mistakes. Indeed, making mistakes is the point of design-it's cheaper to make mistakes and correct designs than it would be to make the same mistakes, recognize them after coding, and have to correct full-blown code. Design is sloppy because a good solution is often only subtly different from a poor one."

Aber wir können die Dinge glätten: "We will never find a process that allows us to design software in a perfectly rational way. The good news is that we can fake it. We can present our system to others as if we had been rational designers and it pays to pretend do so during development and maintenance." Warum man das tun soll, wurde auch argumentiert.

Dies (die Glättung am Ende) ist ein Grund, warum man leicht Designprozess und Resultat verwechseln und fälschlicherweise annehmen kann, Softwareentwicklerinnen handelten bei der objektorientierten Analyse (wohlgemerkt: ein Prozess in der Gesellschaft) wie rationale Agenten:

"In Grundsatzdiskussionen werden Typen und Begriffe, Extensionen und Intensionen, Mechanik und Überlegung, gerne gegeneinander ausgespielt. Das Bild, das sich aus der gegenwärtigen Diskussion ergibt, ist differenzierter. Objekte und Gegenstände, bzw. Klassen und Begriffe, stammen aus unterschiedlichen Problembereichen. Eine Abstraktionsstufe höher ist die Differenz auflösbar. Die meisten gesellschaftlichen Prozesse enthalten jedoch eine Mischung aus Steuerung und Argumentation." (H.H.)

Ordnung im Code?

"Ironischerweise bedient sich die objektorientierte Analyse also eines antiken Schemas, dessen Plausibilität zur Modellierung des Erkenntnisvorgangs vielfach angezweifelt worden ist. Aktuelle Konzeptionen vertreten die Auffassung, daß sich die Orientierung in der Welt, genau gesagt die uns zugängliche Welt selber, zusammen mit dem Begriffsgebrauch entwickelt. Das heißt: in der sprachlich vermittelten Strukturierung der Umwelt an Hand von Aussagesätzen. Die Prioritäten Platons werden dabei umgedreht: am Anfang steht kein überzeitlicher Typus, sondern der im diskursiven Prozeß verankerte Entwurf von Ordnungsstrukturen." (H.H.)

Im Prozess der objekt-orientierten Analyse bedient man sich dem antiken Schema. Was interessant ist: Dieses Schema tritt nicht auf mit dem Anspruch, eine adäquate Beschreibung der Funktionsweise unseres Erkenntnisprozesses zu sein, sondern stützt sich auf die Einfachheit ihrer Resultate. So strukturierter Programmcode und Dokumentationsmaterial hat eine höhere Chance, verwaltbar und - was hätte Platon dazu gesagt? - veränderbar zu bleiben. Er ist überblickbar (hier sind wir wieder beim Sehen), funktioniert nach wohldefinierten Hierarchien und birgt keine Überraschungen - der Idee nach. Die Praxis im Umgang mit den Gegenständen der Welt sieht anders aus, das bleibt keiner Programmiererin erspart und man hat sich mit iterativen Methoden mittlerweile daran gewöhnt. Man erstellt Proto-Typen.

Unser Code-Beispiel vom Buch in Inform7 ist ein typisches Schulbeispiel: Es zeigt nur das Resultat und stellt den heuristischen (und diskursiven) Prozess, in dem das Verhalten und die Charakteristika des Gegenstandes in steuerbare Objekte nachgehamt werden, in den Schatten - da hilft auch der Prosa-Stil der Programmiersprache nicht. Doch das ist eine Pointe des Programmierens: Das Matching von Prozessen und Gegenständen aus unserer Lebenswelt in Abläufe aus der Objektwelt, die dann in unsere Lebenswelt rückwirken und bestimmten Zwecken dienen.

Es gibt also mindestens zweierlei Nachahmungen in objekt-orientierter Softwareentwicklung: Die Nachahmung der Charakteristika des Gegenstandes (von unserer Lebenswelt in die Welt der Objekte) und die Nachahmung des antiken Schemas einer rationalen und systematischen Top-Down-Methode für Dokumentations- und Demonstrationszwecke obwohl man weiß dass man damit keinen Tag durchkommen wird. Durch letztere Nachahmung wird ein Haufen von Symbolketten leichter versteh- und diskutierbar. Sie ist sozuagen Nützliche Fiktion. --Andyk 00:43, 6. Jan. 2011 (UTC)