Vorstellung der Sprache C-mol - methodenorientierte Softwareentwicklung
-
Helium schrieb:
bei Bedarf auch Template-Handling
Was heißt das nun wieder?
Ein Handling kann auch als Template implementiert sein. Das Schlüsselwort 'that' nimmt dann immer den jeweiligen speziellen Template-Typ an.
Helium schrieb:
Uns selbst wenn diese Bibliothek gigantisch wäre könnte Sie trotzdem keine MO-Methoden enthalten, da ich unter Garantie für meine Zwecke Klassen spezialisieren muss, die dann natürlich nicht von der Methode abgedeckt würden.
Zum einen kannst Du ja dann von einer Methode erben und die Handlings, die Dir fehlen ergänzen. Zum anderen kannst Du zum Beispiel auch ein Handling für eine Basisklasse definieren, welches dann auch Objekte aller abgeleiteten Klassen verarbeiten kann.
Helium schrieb:
Um mein Problem mit der MO nochmal etwas rauszuheben: In der OO kann ich tausende Klassen von einer gemeinsamen Basis ableiten und alle werden mit Funktionen, die für die Basisklasse gedacht sind arbeiten. Aber ich kann wohl kaum mehrere Methoden parallel aufleiten.
Doch, das geht. Warum nicht?
Helium schrieb:
Das macht keinen Sinn. Methoden sind ja nicht Polymorph und nicht, wie Objekte, übergebbar. Das heißt ich kann einer Funktion, die eine Methode verwendet stattdessen eine Aufgeleitete Methode verwenen lassen. Ich habe auch keine Ahnung, wie ih mir das vorstellen soll.
Naja, Methoden sind polymorph für alle Datentypen, die sie behandeln. Du kannst beispielsweise ein Template-Handling machen, in dem eine zweite Methode aufgerufen wird, die von einer oder mehreren Methoden erben muss, bzw. alle Handlings zur Verfügung stellen muss, die für das Template in Frage kommen.
Alternativ, könntest Du statt des Template-Handlings ein Handling für einen Basisklassentyp verwenden, wenn Du die Verarbeitung auf einen bestimmten Zweig einer Hierarchie beschränken willst (was in C-mol jedoch nicht umbedingt notwendig ist, da der C-mol Polymorphismus ein "erweiterter" Polymorphismus ist und auch mit Klassen verschiedener Hierarchien funktioniert, die also keine gemeinsame Basisklasse haben!).Helium schrieb:
void fertiger_Code (Basis & objekt) { ... mo_methode()°&objekt(); ... }Sowas kann nicht gehen. Wird die Hirachie, die an 'Basis' hängt (egal, was Basis jetzt ist) erweitert muss ich direkt die Methode abändern, was ich vielleicht nicht darf oder kann. Aufleiten bringt mir gar nichts. Eine Erweiterung der Hirachie funktioniert also nicht, bzw. ich kann das Verhalten für meine Hirachieerweiterung nicht angeben.
Doch, so wie oben beschrieben geht's! Eine (aufgeleitete) Methode muss dann als Schnittstelle für die Implementierungen dienen.
Allerdings könnte man vielleicht darüber nachdenken wie man das noch schöner machen kann. Aber C-mol befindet sich ja auch ständig in der Weiterentwicklung.Helium schrieb:
Ich glaube langsam komme ich dahinter, wofür man die MO benutzen kann. Ich wollte Sie immer innerhalb einer Hirachie einsetzen, was unmöglich zu sein scheint.
Es gibt schon ein paar Möglichkeiten (siehe obere Beschreibungen).
Helium schrieb:
Aber man kann Sie wuederbar einsetzen, um mehrere Hirachien zusammenzuführen. Wenn sich mit zwei oder mehr Hirachien ein und die selbe Aufgabe erledigen lässt, verlagert man diese aufgabe in eine Methode. Diese nutzt indirekt die polymorphen Eigenschaften der jewieligen Hirachien aus, hat also keine Probleme mit Erweiterungen.
Ja! Das auf jeden Fall! Hatte ich ja auch schon mal indirekt in dem Posting vom 12:04:47 30.12.2003 angesprochen.
Vor allem der erweiterte Polymorphismus kommt hier denke ich besonders gut zum Einsatz: Man kann Laufzeit-Polymorphismus auf Klassen unterschiedlicher Hierarchien anwenden. So kann man besonders gut Hierarchien zusammenführen.
-
Wie sieht ein Template-Handling aus?
method Whatever () { Whatever () { ... } ~Whatever () { ... } template <typename T> // so? void <T> () { ... } }Falls ja, wie werden weitere Handlings definiert?
method Whatever () { Whatever () { ... } ~Whatever () { ... } template <typename T> void <T> () { ... } template <> // so? void <int> () { ... } }
-
Helium schrieb:
Wie sieht ein Template-Handling aus?
method Whatever () { Whatever () { ... } ~Whatever () { ... } template <typename T> // so? void <T> () { ... } }Ja, so ist's richtig.
Helium schrieb:
Falls ja, wie werden weitere Handlings definiert?
Hier einige Beispiele:
C-mol Code:
method Whatever() { Whatever() { ... } ~Whatever() { ... } template <typename T> void <T>() { ... } // z.B. so; das wäre ein Handling, was das Template-Handling obendrüber für int spezialisiert void <int>() { ... } // oder so; das wäre ein Handling, was das Template-Handling oben "überlädt" (da das Template ja alles abdeckt) void <int>( char cHp ) { ... } // oder so; das wäre ein weiterer Typ von Template-Handling in der Methode template <typename T> void <T>( float fHp ) { ... } };
-
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.