Follow my new blog

Donnerstag, 28. April 2011

Der Objekte Kern

Was ist eigentlich Objektorientierung? Eigentlich sollte das doch klar sein – und doch erhitzen sich die Gemüter immer wieder darüber. Wenn ich Flow-Design vorstelle, höre ich z.B. den Einwand, das sei doch gar nicht mehr objektorientiert. Das ist dann nicht nur Feststellung, sondern auch Kritik. Aber ist das wirklich so? Und ist das kritikwürdig, wenn es denn so wäre?

Ich denke, wir müssen uns die Objektorientierung ein wenig näher ansehen, um das beurteilen zu können. Die scheinbar eine Objektorientierung gibt es nämlich nicht.

Harte Objektorientierung – Technik

Unter Objektorientierung verstehen die meisten Entwickler zunächst einmal Mittel einer Programmiersprache. Es geht also um Technik, um Code. Diese technische Objektorientierung lässt sich für mich so auf das absolut Essenzielle reduzieren:

Hinter einem Interface verborgene allozierbare strukturierte Speicherbereiche.

Jup, das ist es für mich. Mehr ist technische Objektorientierung nicht. Alles andere ist nice to have, aber nicht wirklich essenziell.

Allozierbarer Speicherbereich: Ein Speicherbereich, den Code durch einen Befehl für sich reklamieren kann; der Code erhält ein Handle für diesen Speicherbereich, so dass er ihn benutzen kann. Der Speicherbereich wird nach einem Schema strukturiert – aber auch das ist nicht zentral für die Objektorientierung.
Da der allozierende Code nur ein Handle auf den Speicherbereich bekommt, weiß er nicht, wo genau der Speicherbereich liegt. Er hat also keinen direkten Zugriff auf ihn.

Interface: Eine Menge von Prozeduren und Funktionen. Nur die Prozeduren und Funktionen des bei der Allokation eines Speicherbereichs angegebenen Interface haben Zugriff auf ihn.

Technische Objektorientierung verbindet also Speicher mit Funktionalität, die auf diesem Speicher arbeitet.

Wie passen dazu aber…

  • Klassen: Klassen sind die Kombination von Schema und Interface. Ihre Felder strukturieren Speicherplatz und ihre Methoden bilden das default Interface für die Arbeit mit dem strukturierten Speicherplatz.
    Speicherallokation findet statt unter Angabe einer Klasse. Sie instanziiert eine Klasse zu einem…
  • Objekte: Objekte sind allozierter, hinter einem Interface verborgener Speicher.
  • Felder: Bereiche mit spezieller Semantik im allozierten Speicherbereich. Das Schema für Speicherbereiche besteht aus Felddefinitionen.
    Von außen sichtbare Felder (public, internal) widersprechen der obigen Definition von technischer Objektorientierung.
  • Prozeduren/Funktionen: Objekte kommunizieren via Nachrichten. Prozeduren und Funktionen sind die nachrichtenverarbeitenden Funktionseinheiten auf Interfaces.
    Ob die Kontinuität der Prozedur/Funktionssyntax von C eine gute Wahl zur Definition dieser Funktionseinheiten war, lasse ich mal dahingestellt.
  • Properties: Prozeduren bzw. Funktionen, die suggerieren, dass ein Durchgriff auf den Speicherbereich von außen möglich ist.
    Von außen sichtbare Properties (public, internal) widersprechen nicht direkt der obigen Definition von technischer Objektorientierung, da es sich ja um Methoden handelt. Dennoch ist Vorsicht angezeigt, denn wo Properties ins Spiel kommen, liegt es nahe, dass Schemadetails nach außen sichtbar gemacht werden.
  • Vererbung: Vererbung ist für die obige Definition von Objektorientierung nicht essenziell. Sie ist nice to have, um hier und da Schemata oder Interfaces wiederzuverwenden.
  • Polymorphie: Polymorphie gehört auch nicht essenziell zur Objektorientierung nach obiger Definition. Sie ist nice to have, um denselben Speicherbereich in unterschiedlichen Zusammenhängen auch durch unterschiedliche Interfaces gekapselt angesprechen zu können.
  • Dynamische Programmierung: Ob das Interface, hinter dem ein Speicherbereich versteckt ist, fix oder dynamisch ist, ist unwesentlich für die obige Definition von Objektorientierung. In einigen Situation ist solche Dynamik nice to have.

Von der Wikipedia-Definition der Objektorientierung bleibt für mich also nur die Kapselung als essenziell übrig. Damit möchte ich nicht den Nutzen von Polymorphie oder Vererbung negieren, sondern nur fokussieren. Um was geht es wirklich, wirklich ganz fundamental bei der Objektorientierung? Eben um hinter einem Interface verborgenen nach einem Schema allozierten Speicher. Nicht mehr, nicht weniger.

Ich würde daher eigentlich auch gern den Begriff “Objekt” aus der Objektorientierung herausnehmen. Er ist mir zu suggestiv. Die scheinbare Entsprechung von programmiersprachlichen Objekten zu realweltlichen hat schon viel Schaden angerichtet.

Für mich geht es eher um Funktionale Strukturen oder so, d.h. nach Schema strukturierte Speicherbereiche wie sie schon C und Pascal kannten – die nun aber eben reflexive Funktionalität tragen. Das gab es in C und Pascal nicht.

Ob der Speicherbereich umfangreich oder detailliert strukturiert ist… das hängt von seinem Zweck ab. Er kann 0 Bytes umfassen oder 2 GB; sein Schema kann kein Feld oder hunderte Felder definieren.

Wie der Umfang des Interface aussieht, ist jedoch relevant. Ist das Interface leer und liegt die Struktur damit zwangsläufig offen (sonst hätte die Umwelt ja keinen Zugriff darauf), dann handelt es sich im Grunde nicht mehr um Objektorientierung. Ihr zentraler Zweck, die Kapselung, wird dann ja nicht mehr verfolgt. (Standardfunktionen wie Equals() oder ToString() zähle ich hier mal nicht mit. Das wirkliche Interface eines Objektes beginnt erst jenseits von ihnen.)

Die Entwicklung hin zur Objektorientierung ähnelt mithin ein wenig der Entwicklung primitiven Lebens. Dessen Evolution führte von einzelnen Molekülen über semilebendige Ansammlungen (die heutigen Zellorganellen) zu Zellen. Der entscheidende Schritt war dabei der der Entwicklung einer Membran, d.h. die Schaffung einer Blase. Die Membran oder Zellwand trennt Innenwelt von Außenwelt. Sie entkoppelt das Zellinnere von der Umwelt und ermöglicht damit den Aufbau von Zustand in gewisser Unabhängigkeit.

image

Das Wesentliche an Objektorientierung ist also, dass sie Speicherplatzdetails (Ort und Schema) von der Umwelt, d.h. seiner Verwendung entkoppelt. Objektorientierung dreht sich um Kapselung, Kapselung, Kapselung. Und alles, was die Kapselung aufweicht, widerspricht ihr.

Nicht, dass ungekapselte strukturierte Speicherbereiche sinnlos wären. Man spricht dann nur besser nicht mehr von Objektorientierung.

Ein weiteres Argument spricht dafür, dass offengelegte Speicherbereiche keine Objekte sind. Die Kommunikation mit ihnen erfolgt dann nämlich nicht mehr über Nachrichten. Sie kann es nicht, weil Nachrichten Funktionalität zur Verarbeitung brauchen. Eine Nachricht selbst besteht ja nur aus Daten. Ohne passende Interfacemethode können die aber nicht verarbeitet werden. Daten direkt in einen Speicherbereich zu legen, ist keine Funktionalität, die ein Objekt bräuchte; das konnten schon C und Pascal.

Technisch essenzielle Objektorientierung braucht also sehr wenig. Sie kann mit einer Untermene von C# oder Java betrieben werden. Klassen, Methoden, private/protected Felder, Interfaces – das ist es. Vererbung, Properties… nicht nötig. Für den Zweck der Kapselung reichen wenige Mittel. Alles andere ist nice to have; wir sollten uns darüber nicht die Köpfe heiß reden. Das wäre am wirklich spannenden Thema vorbei. Das ist nämlich: Wie sollte mit technischer Objektorientierung umgegangen werden?

Weiche Objektorientierung – Methode

Von der technischen Objektorientierung ist zu trennen der Umgang mit ihr. Technische Objekte sind “leer”, d.h. sie geben nicht vor, wie man sie benutzt. Technische Objekte sind sozusagen nur “kleine C Programme” (d.h. Einheiten von Daten und Funktionalität). Die Frage ist also: Wie sollte ein Problem in viele, viele “kleine C Programme” zerlegt werden, damit etwas qualitativ hochwertiges herauskommt?

Dazu gibt es mehrere Ansätze. Der am weitesten verbreitete ist der von Objektorientierte Analyse und Design (OOAD) – oder noch nicht einmal. Verbreitet ist eher eine stark abgespeckte Version davon, sozusagen OOAD ultra light (OOADUL) :-)

Das primäre Entwurfsmittel von OOADUL – wenn denn überhaupt expliziter Codeentwurf stattfindet – ist das Klassendiagramm. Und das primäre Vorgehen ist die Suche nach Substantiven in Anforderungen. Bei einem Tic Tac Toe Spiel würden sofort Spiel, Spieler, Spielbrett, Spielstein als Objektkandidaten identifiziert werden – um dann auf ihnen irgendwie erstens Zustand und zweitens Funktionalität zu verteilen.

Die Prämisse bei OOADUL lautet: Software besteht aus Objekten, die nahe an der realen Welt sind. Was in der Problemdomäne zu sehen und anzufassen ist, das liegt nahe in problemlösenden Software als Objekte repräsentiert zu sein.

An dieser Stelle will ich diesen Ansatz nicht bewerten, sondern ihn nur darstellen. Mir ist im Augenblick wichtiger, ihn als Methode zu trennen von der technischen Objektorientierung.

Zusammenschau

Konzeptionelle/methodische Objektorientierung und technische Objektorientierung sind zwei Paar Schuhe. Man kann auch methodisch objektorientiert Software planen – und dann mit einer technisch nicht objektorientierten Programmiersprache umsetzen. Und umgekehrt.

Technische Objektorientierung ist ein leeres oder neutrales Werkzeug. Es dient durch die Kombination von Daten und Funktionalität im Verein mit der konsequenten Kapselung dem wohl ältesten Prinzip der Softwareentwicklung: der Entkopplung. “Neumodischer Krams” wie Properties oder auch Altmodisches wie öffentliche Felder widersprechen dem jedoch. Deshalb kann man sie trotzdem anwenden – muss nur eben wissen, dass man sich damit jenseits der Objektorientierung bewegt.

Zurück zum Ausgangspunkt: die oft erhitzten Gemüter. Wo sich nun die Gemüter über die Objektorientierung erhitzen, da sollte als erstes gefragt werden, worum es geht. Erhitzt man sich über die Methode oder die Technik?

Mein Gefühl ist, dass die Diskussionen sich weniger um technische Objektorientierung drehen. Die, die am Wert der technischen Objektorientierung zweifeln, treffen einfach relativ selten auf Freunde der technischen Objektorientierung. Am Ende ist sie ja auch unkritisch. Solche Daten-Funktionalität-Blasen zu haben, ist einfach eine nützliche Sache. Warum darauf verzichten.

Viel schwieriger und inzwischen kontroverser ist jedoch, wie mit diesen Blasen umgehen? Hitzige Diskussionen entstehen, wenn die Methode angezweifelt wird. (Oder auch, wenn es um die Methode geht, aber jemand glaubt, es ginge um die Technik.)

Auch ich wende mich mit Flow-Design gegen die Methode und nicht gegen die Technik. Zukünftig will ich das noch besser deutlich machen, um Missverständnissen vorzubeugen. Flow-Design ist eine Methode, um Software zu entwerfen. Und Event-Based Components (EBC) sind eine Übersetzung von Flow-Designs in C# Code; da geht es also um die Nutzung objektorientierter Technik.

Wer Flow-Design für kritikwürdig hält, weil es nicht der (oder seiner Sicht auf die) Objektorientierung entspricht, der muss sich also mit seinen Argumenten auf der methodischen Ebene bewegen. Pauschal zu sagen, Flow-Design sei nicht objektorientiert, ist mithin falsch. Flow-Design ist nur methodisch nicht objektorientiert; und mit der Technik hat Flow-Design nichts zu schaffen.

Und wer Event-Based Components als nicht objektorientiert kritisiert, der muss sich auf Technik konzentrieren. Er muss zeigen, inwiefern EBC der technischen Objektorientierung widerspricht. Und das wird schwer, würde ich sagen :-)

Kommentare:

Anonym hat gesagt…

Jetzt bin ich ziemlich fassungslos ...

Was soll das? Anstatt zu zeigen, welchen Fortschritt EBC bzgl. Objektorientierung bei der Softwareentwicklung bedeuten kann, wird die Objektorientierung "nieder gemacht".

Gratulation!

Auf die "Kritik", EBC sei nicht oder zu wenig "objektorientiert" derart beleidigt zu reagieren, indem man objektorientierte Softwareentwicklung - weil es passt - auf das "Minimum" reduziert, und dann schlussfolgert, ihr spielt ja nur in der Sandkiste und könnt nicht mal das richtig, ist wirklich armselig.

Bei Neuerungen war/ist immer mit Gegenwind zu rechnen.
Bei Neuerungen war/ist es immer erforderlich, sich mit dem "Bisherigen" auseinanderzusetzen.

Ralf, Du willst überzeugen und fachst das Feuer des Konflikts noch mehr an.

Anonym hat gesagt…

Hm. Mir gefällt der Artikel auch nicht.

Mit der Argumentation kann ich nämlich alles als objektorientiert darstellen, solange es ein Interface hat: Dann ist auch eine simple int-Variable schon objektorientiert, weil auch int ein bestimmtes Interface aufweist, und ich einen bestimmten Speicherbereich (32 Bit) in einer bestimmten Struktur (Big-Endian / Little-Endian) für mich allokieren kann.

Das greift zu kurz.

Dass auch EBCs / Flow-Design dann objektorientiert seien, ist logisch - nur geht das am Kern der Kritik vorbei, dass es mit OOP nichts zu tun hätte.

Ralf Westphal - One Man Think Tank hat gesagt…

@Anonym: Du wirfst mir vor, die Objektorientierung nieder zu machen.

Deshalb gleich die Frage an dich: Welche denn? Meinst du, ich mache die technische oder die methodische Objektorientierung nieder?

Siehst du, wie nützlich die Unterscheidung ist?

Und dann zeige mir bitte in meinem Text den Satz, in dem ich ein Urteil über diejenige Objektorientierung fälle, von der du meinst, dass ich sie niedermache. Wo fälle ich ein Urteil und sage, "die technische Objektorientierung ist Mist" oder "die methodische Objektorientierung ist Mist"?

Ich sehe solch einen Satz in diesem Beitrag nicht. Du hast also keinen Grund, fassungslos zu sein.

Deiner Forderung, ich solle zeigen, welche Fortschritte EBC bzgl. (technischer) Objektorientierung bringe, kann ich nicht nachkommen. EBC verbessert ja die technische Objektorientierung nicht, sondern wendet sie nur in gewisser Weise an.

Inwiefern allerdings Flow-Design mit EBC zu einer besseren Nutzung von technischer Objektorientierung führt, habe ich schon an anderer Stelle versucht darzustellen und werde es natürlich weiter tun. Dafür ist dieser Beitrag wichtig, denn der macht nun klar, worüber ich bei Flow-Design rede: über eine Methode zur Planung von technisch objektorientierten Strukturen. (Man kann Flow-Designs zwar auch anders übersetzen, doch wir nutzen heute halt OOP Sprachen.)

Ich bin auch gar nicht begleidigt. Und schon gar nicht reduziere ich deshalb die technische Objektorientierung auf ein Minimum. Auch halte ich niemandem eine Sandkiste vor. Wo liest du das denn raus - allemal nicht in Bezug auf technische Objektorientierung. In der Sandkiste würde ich ja selbst spielen.

Allerdings zweifle ich den Nutzen der methodischen (!) Objektorientierung an. Nicht in diesem Beitrag zwar, aber in anderen. Dafür habe ich ne Menge Argumente sehr grundsätzlicher wie auch praktischer Art.

Und bisher - so muss ich sagen - hat mir noch kein Vertreter der methodischen (!) Objektorientierung in einer Gegenüberstellung gezeigt, dass seine Methode schneller zu besser evolvierbarerem und korrekterem Code führt. Aber vielleicht willst du diese Herausforderung ja annehmen.

Nochmal: Technische Objektorientierung find ich völlig ok und nutze sie - sogar meist nur in der von mir definierten minimalen Form.

Methodische Objektorientierung hingegen kritisiere ich. Nicht beleidigt, sondern auf der Basis von Praxiserfahrung und fundamentalen Prinzipien.

Ralf Westphal - One Man Think Tank hat gesagt…

@Anonym #2: Tut mir leid, wenn auch dir der Artikel nicht gefällt. (Im Grunde habe ich das aber auch nicht anders erwartet. Hier gehts ja ans Heiligste der Softwareentwicklung.)

Du sagst: "Mit der Argumentation kann ich nämlich alles als objektorientiert darstellen, solange es ein Interface hat: Dann ist auch eine simple int-Variable schon objektorientier" und meinst das als Kritik.

Tatsächlich ist aber genau das schon technische Objektorientierung. So lebt es C# und ist stolz drauf. Sonst würde 1.ToString() nicht funktionieren. Und so war es noch extremer bei quasi der Ursprache der Objektorientierung: Smalltalk.

Dass dir pers. das nicht schmeckt... schade. Aber vielleicht auch ein Zeichen dafür, dass selbst die technische Objektorientierung nicht wirklich in der Entwicklergemeinde angekommen ist.

Und dann:
"Dass auch EBCs / Flow-Design dann objektorientiert seien, ist logisch - nur geht das am Kern der Kritik vorbei, dass es mit OOP nichts zu tun hätte."

Welche Objektorientierung meinst du?

Aber ich will helfen:

Flow-Design kann nicht technisch objektorientiert sein, weil es eine Methode ist. Und sie ist methodisch nicht objektorientiert, weil sie genau das nicht sein will.

Da hast du also etwas falsch verstanden.

EBC sind auf technischer Ebene und nutzen die teschnische Objektorientierung. Ganz genau. Und das ist auch keine Interpretationsfrage, sondern evident. Wenn die Funktionseinheit F so übersetzt wird:

class F {
public void Process(...) {...}

private int SomeHelperFunction(...) {...}

public event Action Result;
}

Dann ist das eindeutig technische Objektorientierung mit Genuss.

Die mag nicht dem folgen, was die methodische Objektorientierung sich so vorstellt, wie man mit technischer Objektorientierung umgeht... aber das ist egal. Technisch bleibt es objektorientiert.

Sven hat gesagt…

Ich mag diesen Blog inklusive der Kommentare. Es wird immer alles so lange umdefiniert bis es passt :) Das ist lustig

Frank Jurisch hat gesagt…

Mal wieder der Versuch einer Mitmischung. Die bisherigen landeten in den Entwürfen, weil ich mich überhitzte aus Protest gegen das Kind dass mit dem Bade in der Rethorik schwamm. Zuerst schien es hier auch harmlos, technisch. Die Reaktion zeigt wieder emotionale Betroffenheit. Natürlich muss sich jeder ausgeschüttet fühlen der einen ganzen Nationalpark mit Objekten zu hüten versucht und dann nur OOADUL sein soll. @anonym #1 klingt jedenfalls mindestens wie ein Zoodirektor. Deine Argumentation gegen Täter- oder Domänen(nichtanämische)-Objekte klingt auch immer wieder seltsam agressiv wenn man EBCs scheinbar nicht auch als Täter-Objekte betrachten soll oder als datenfrei. Ob das soooo gesagt wurde oder nicht entsteht immer wieder der Eindruck dass EBC das mehr ablösen soll als intendiert.
Wer sich EBC ansieht kann OO nicht vermissen. Eher im Gegenteil, die Menge der beteiligten Objekte schwillt ja immer mehr an. Es wirkt fast wie das Gegenteil der Gott-Klassen: totaler Zerfall in unüberschaubare Einzeltäter. Aber alle werden OO-mäßig verbandelt mit Hilfe der in der Objekt-Definition nicht erwähnten Nützlichkeit der Kontrakte. Mag sein die sind auch ohne OO irgendwie zu haben aber nicht in unserem Sprachraum.

Leider hab ich verpasst wo EBC als zu wenig objektorientiert sachlich (am Beispiel) kritisiert wird. Ich sehe schlimmstenfalls eine partielle Überbetonung der Nützlichkeit in der Argumentation. Es ist halt schon ein wenig anders alles über ResultEvents weiterzuleiten als aus Returnvalus zu fordern. Eigentlich aber eine korrekte Weiterentwicklung von "Frag nich sonder sag was du willst" (irgendwo bei Fowler? jedenfalls für mich eine prinzipiell korrekte Herangehensweise an ungewisse Situationen die ich eh nicht überblicken kann/will, dazu kann ich ja im EBC auch ein OnError haben oder in seinem Kumpel oder noch näher an dem der weiß wo es klemmt, ich (der Ergebniswünscher) muss mich nur auf beides vorbereiten ).
Für mich ersetzt EBC nicht OOAOOD sondern verfeinert das in Richtung Handhabbarkeit für den eigentlich abzubildenden Arbeitsschritt. Es ist anfangs komplizierter die Wünsche zu formulieren wenn man an Services denken muss die jetzt nicht mehr prozedural antworten. Gar wenn alle anderen Mitspieler das aber (jetzt) doch tun. Ich persönlich hasse es gefragt zu werden ob ich Lust hab "diese unangenehme Tätigkeit" auszuführen. Ich bekomme den Auftrag und antworte mit dem Ergebnis oder/und einer Statusmeldung. Letztere kann auch heißen: frag mich nich. In persönlichen Verhältnissen kann das komliziert sein. EBC machen diese Sache nicht unkomplizieter. Man vergleiche die Dauerfrage nach der Unterbringung der Validierung. Wenn es eine Eingangsvalidierung braucht ist eine Prä-Commit-Validierung nicht überflüssig und auch nicht umgekehrt.

Mir scheint ich sollte das wieder zu den Entwürfen werfen. Ich kann leider eine Frage nie ohne den Zusammenhang beantworten. Andere schreiben dann Bücher, da war ich doch kurz, oder ?-)

sdechi hat gesagt…

Hallo Herr Westphal,

Zunächst einmal danke für diesen Blog Post, den er regt zum denken an und aktiviert mal wieder vergessenes Wissen :)

Nun zum inhaltlichen, die Definition der technischen Objektorientierung, ist das eine geschaffene Definition oder gibt es Referenzen die dies genauso sehen.

Persönlich finde ich EBC und Flow Design einen neuen interessanten Ansatz in der Informatik. Allerdings weckt es für mich auch oft ungewollt die Assoziation zu SPS Systemen aus der Automatisierungstechnik. Was ich bei diesen Systemen gelernt habe ist, nicht nur weil etwas von aussen wie eine schöne Komponente aussieht ist sie das auch in ihrer Implementierung, aber ich glaube dazu jetzt alle meine Gedanken auszuführen ist wohl eher so etwas für eine Flasche Rotwein als für ein Blog Kommentar.

Anyway, ich freue mich wirklich darauf noch etwas mehr über die technische Objektorientierung zu lesen. Vielleicht kommt die Debatte zu den EBCs auch nur davon das, man ein kommunikatives Problem hat und mach die technische Objektorientierung in dieser weise wie hier beschrieben einfach nicht als "landläufige" Definition kennt. Vielleicht sollte man die Leute erst dafür begeistern und dann den schritt weiter gehen :)

So lange habe ich noch eine recht nette Definition von object oriented in einem Paper des Erfinders von C++ auf Lager und möchte das mal so ohne Wertung stehen lassen.

Zu finden hier: http://www2.research.att.com/~bs/oopsla.pdf

Ich freue mich wirklich sehr mehr davon zu hören denke aber auch das wie hier in diesem Artikel beschrieben die methodische Objektorientierung seine Bewandtnis hat.

Ralf Westphal - One Man Think Tank hat gesagt…

@sdechi: Die Definition von techn. OOP, die ich gegeben habe, ist meine. Für mich stellt sie das minimale Destillat dar. Vererbung fehlt hier ganz bewusst. Insofern gehe ich auch nicht mit Bjarne Stroustroup konform. (C++ ist für mich trotz seiner Verbreitung auch eher ein Problem denn eine Lösung.)

Wer mir eine Definition von techn. OOP "gestatten" sollte, weiß ich nicht. Niemand muss da um Erlaubnis fragen, sondern sich nur einem Diskurs stellen. Das tue ich.

Anonym hat gesagt…

Eine typische Diskussion über Objektorientierung. Schaut euch doch mal an wo die heutige Objektorientierung ihre Wurzeln hat. C#, Java usw. ist doch nicht wirklich Objektorientierung ;-) es ist eher Klassenorientierung. Mit Weichmachern wie Interfaces. Übrigens kommt EBC der originalen Objektorientierung sehr nahe.
Ich denke nicht das Ralf hier etwas nieder machen wollte. Es ging darum wichtiges von unwichtigem zu trennen. Natürlich nur aus einer konkreten Perspektive betrachtet.

Übrigens: Wer mal eine nettes Composer UI sehen möchte wie EBC aussehen könnte, nehme einen Standard Mac OS X mit Standard Development und starte dort Quartz Composer.. ist nur für Grafik, aber da ist alles drin was hier über EBC gesprochen wurde... sogar mit Platinen (dort Macros genannt)