Vorstellung der Sprache C-mol - methodenorientierte Softwareentwicklung
-
SendKey schrieb:
Man kann doch nicht sagen, dass es kompliziert(er) aussieht, oder? Aber vielleicht ist es auch einfach nur Geschmackssache...
nein kann man nicht (abgesehen davon, dass es nicht mein beispiel war, und die template-version kürzer/übersichtlicher war). und genau das ist das problem: es gibt keinen vorteil, den ich erhalte. darum werd ich mir c-mol erst dann aneignen, wenns ein arbeitgeber von mir verlangt. vorher wahrscheinlich nicht, weil ich keinen gewinn sehe. gehört habe ich jetz davon, und weis dass es sowas gibt, werde darauf zurückkommen, wenns eine situation gibt, die ich (wenn ich mit c++ arbeite) mit c++ nicht mehr sauber bewältigen kann. aber das kann dauern
[gemein]eine spracherweiterung die keiner braucht[/gemein]
(ich lass mich eines besseren belehren, sobald ich die sprache mal brauch)
-
Also, vereinfacht ausgedrückt, MOP ermöglicht es, aus Methoden Objekte zu machen ?
Prolog / Epilog sind dann die Konstruktoren/Destruktoren dieser Methode-objekte ?
-
@.not:
So direkt kann man das nicht sagen. Methoden lassen sich im Gegensatz zu Klassen beispielsweise nicht instanziien. Prolog und Epilog werden bei jedem Methodenaufruf vor bzw. nach dem entsprechenden Handling ausgeführt und können so Code, der für jedes Handling ausgeführt werden soll zusammenfassen.Für den Einstieg kann ich dieses Dokument empfehlen:
http://www.mosd.net/files/MOP-Overview.pdfKorbinian schrieb:
nein kann man nicht (abgesehen davon, dass es nicht mein beispiel war, und die template-version kürzer/übersichtlicher war).
Wieso war das nicht Dein Beispiel?
Nochmal wegen Beispielen:
In diesen Folien findest Du nochmal eines was Dir gefallen könnte!
http://www.mosd.net/files/VortragsfolienInformatiktage.pdf
-
also vielleicht hab ich den c-mol code verstanden. mir gings aber darum, dass in den spezifischen methoden ein teil existiert, der für alle gleich ist. also etwa so:
method Bla { Bla(); ~Bla(); void <Klasse1>() { SpezKlasse1_Teil_1(); DasMussBeiAllenAusgefuertWerdenAberErstNachdemSchonWasSpezifischesGemachtWurde(); SpezKlasse1_Teil_2(); } void <Klasse2>() { SpezKlasse2_Teil_1(); DasMussBeiAllenAusgefuertWerdenAberErstNachdemSchonWasSpezifischesGemachtWurde(); SpezKlasse2_Teil_2(); } void DasMussBeiAllenAusgefuertWerdenAberErstNachdemSchonWasSpezifischesGemachtWurde(); // ... method SpezKlasse1_Teil_1 {}... }müsste aber eigentlich auch einfach mit c-mol machbar sein (einfach ein paar methoden mehr), aber ist es dann nicht recht unübersichtlich?
die beispiele hab ich mir schon angeschaut. das sind halt beispiele, die mit "normalem" c++ genauso komfortabel gemacht werden können. ich werd mir mal im detail anschauen, wieviel aufwändiger die c++ lösungen sind
-
Mal was ganz anderes: Weso der Name Methode? In der Objektorientierung existiert dieser Begriff ebenfalls. Dort ist er recht einleuchtend. Eine Methode beschreibt, wie ein Objekt auf eine bestimmte Nachricht reagiert. Wenn du einem String sagst, dreh dich um, wird er die Rehenfolge seines Inhalts umdrehen, wenn du einer Spielfigur sagst, dreh dich um, wird Sie in die entgegengesetzte Richtung schauen. Es ist eben die Methode des Objekts auf etwas zu reagieren.
In der MO verstehe ich das hingegen garnicht. Wessen Methode etwas zu machen ist es? Vor allem, da es nur eine "Methode" mit gleichem Namen gibt, macht das ganze noch weniger Sinn. Wenn es doch nur eine Art gibt eine Aufgabe zu bewältigen, was hat das dann noch mit dem Begriff Methode zu tun? Ich meine, es muss ja einen sehr triftigen Grund geben, weil der Begriff leicht zu Verwirrungen mit der OO führt.
-
Korbinian schrieb:
also vielleicht hab ich den c-mol code verstanden. mir gings aber darum, dass in den spezifischen methoden ein teil existiert, der für alle gleich ist. also etwa so:
method Bla { Bla(); ~Bla(); void <Klasse1>() { SpezKlasse1_Teil_1(); DasMussBeiAllenAusgefuertWerdenAberErstNachdemSchonWasSpezifischesGemachtWurde(); SpezKlasse1_Teil_2(); } void <Klasse2>() { SpezKlasse2_Teil_1(); DasMussBeiAllenAusgefuertWerdenAberErstNachdemSchonWasSpezifischesGemachtWurde(); SpezKlasse2_Teil_2(); } void DasMussBeiAllenAusgefuertWerdenAberErstNachdemSchonWasSpezifischesGemachtWurde(); // ... method SpezKlasse1_Teil_1 {}... }müsste aber eigentlich auch einfach mit c-mol machbar sein (einfach ein paar methoden mehr), aber ist es dann nicht recht unübersichtlich?
Also wie gesagt, das geht so, wie ich es in diesem Posting beschrieben hab: 13:35:49 03.01.2004.
Ich denke, dass ist genau das was Du meinst! Man braucht dazu genau drei Methoden, wenn man es rein methodenorientiert lösen will. Ich denke es wird dadurch auch nicht unübersichtlicher, weil man bei einem methodenorientierten Projekt ja davon ausgeht, dass in jeder Methode Codeteile implementiert sind, die auch zusammengehören und man somit in diesem Fall eine schöne Trennung zwischen allen gleichen und allen spezifischen Codeteilen am Anfung und am Ende hat. Außerdem werden die Codeteile alle implizit korrekt aufgerufen, ohne dass der Programmierer daran denken muss bestimmte Funktionen aufzurufen oder eine Reihenfolge einzuhalten.
Falls einem dass zu aufwendig ist (z.B. in einem kleineren Projekt) kann man ja notfalls immer noch eine normale Funktion für den Zwischenteil aufrufen.Korbinian schrieb:
die beispiele hab ich mir schon angeschaut. das sind halt beispiele, die mit "normalem" c++ genauso komfortabel gemacht werden können. ich werd mir mal im detail anschauen, wieviel aufwändiger die c++ lösungen sind
Aber die Idee von methodenorientierter Entwicklung liegt ja vor allem darin, dass man sich nicht explizit darum kümmern muss, das Problem komfortabel, ohne Coderedundanz, etc. zu lösen, sondern dass diese Vorteile automatisch entstehen, wenn man das System in Methoden entwickelt.
Die Beispiele, die wir in dieser Diskussion gesehen haben waren oft sehr gute C++ Alternativen zu den C-mol Ansätzen, aber meiner Meinung nach musste bei den meisten davon beim Entwurf sehr genau darauf geachtet werden Code-Redundanz, etc. zu vermeiden. In diesen Fällen hat man schon wieder eine sehr starke Verschmelzung zwischen einem technischen Problem (nämlich den Code möglichst redundanzfrei und effizient zu implementieren) und der eigentlichen semantischen Programmplanung. Hier setzt ja C-mol an und sagt: "Entwickelst Du in Methoden hast Du ein semantisches Programmkonzept, bei dessen Implementierung diese Art von technischen Problemen nicht auftreten werden."
Genauso wie C++ einst gegenüber C viele Vorteile bei der logischen Strukturierung eines Programms eingeführt hat, die sich sowohl in der semantischen Entwicklung äußern, sich aber auch bei der Umsetzung direkt positiv auf die Implementierung auswirken.
Es gibt ja auch das bekannte "Paradoxon der Softwareentwicklung", welches besagt, dass man um eine Software wirklich gut designen zu können die Lösung des Problems schon vorher kennen müsste. Alle Entwicklungsstrategien können sich nur versuchen daran anzunähern, da man die Lösung eben (meistens zumindest) nicht schon vorher kennt.@Helium:
Letztlich ist es ja ähnlich wie in C++: Eine C-mol-Methode beschreibt, wie die zu behandelnden Datentypen auf die entsprechende Nachricht reagieren sollen. Der Name einer C-mol-Methode gibt dabei die Nachricht aus semantischer Sicht an, auch wenn aus technischer Sicht die Implementierungen für einzelne Datentypen verschieden sein können. Es ist eben alles nur ausgegleidert in eine C-mol-Methode. Dadurch dass es den selben Namen trägt, wie die C++-Methoden kann sich jeder C++-Programmierer sofort etwas darunter vorstellen.
Es ist also im Prinzip schon dasselbe nur kann man eben nicht mehr fragen: Wessen Methode ist es? Sondern es ist ein allgemeiner semantischer Baustein, *für* alle in der C-mol-Methode enthaltenen Datentypen.
Entwickelt man mit C-mol denkt man quasi ein Bisschen "in die andere Richtung": Ich komme nicht vom Entwurf der Klassen zu deren Inhalt: nämlich Attribute und *Methoden*, sondern ich komme von den Methoden zu den Datenstrukturen, die verarbeitet werden sollen. Ich leite nicht ab, sondern ich leite auf (top-down/bottom-up), etc.
-
Aber es wird doch nicht beschrieben, was das Objekt macht, sondern was mit dem Objekt gemacht wird. Ist dann nicht sowas, wie Aufgabenorientierung sinnvoller?
-
@Helium:
Naja, ich weiß was Du meinst. Aber ist es nicht auch ein Bisschen Auslegungssache?
Es ist eben ein Entwicklungsansatz, der sich primär an den "Tätigkeiten" einer Software orientiert.
-
Also Tätigkeitenorientierung?
-
Ja, warum nicht. Ich bevorzuge "Methodenorientierung", weil es meiner Meinung nach besser darauf hinweist, um was es dabei geht. Aber das ist sehr subjektiv. Letztlich kann man Methoden ja auch als die "Tätigkeiten der Objekte" betrachten.