Vorstellung der Sprache C-mol - methodenorientierte Softwareentwicklung

Marc++us

Zur Info, folgende Email bekam ich dieser Tage:

*In dieser Mail möchte ich Ihnen nun noch kurz einige zusätzliche Informationen zu dieser neuartigen Sprache (bzw. Spracherweiterung der Sprache C++) liefern.

Die Sprache C-mol wurde 2001 zusammen mit dem Konzept der methodenorientierten Softwareentwicklung in Mainz entworfen und implementiert. Als erste Programmiersprache, die die Konzepte der methodenorientierten Softwareentwicklung unterstützt, sollte sie zunächst dazu dienen, die methodenorientierte Softwareentwicklung in der Praxis zu erforschen.
Die methodenorientierte Softwareentwicklung stellt dabei einen parallel zur objektorientierten Softwareentwicklung existierenden Entwicklungsansatz dar, welcher Hand in Hand mit der Objektorientierung angewendet werden kann und besonders auf Vorteile wie Codereduzierung und Vermeidung von redundanten Implementierungen sowie Zugewinn an Übersichtlichkeit und Verbesserung der Codewartung ausgelegt ist. Weiterhin wird so durch die methodenorientierte Softwareentwicklung ein sauberer bottom-up Entwurf von Softwareprojekten impliziert.

Die Sprache C-mol unterstützt alle modernen Entwicklungskonzepte wie Vererbung (durch "aufleiten" von Methoden (bottom-up)) und Polymorphismus (in erweiterter Form) sowie Templates, etc.
Außerdem werden alle C++ Sprachfeatures unterstützt und können so mit den methodenorientierten Konzepten aus C-mol verschmolzen werden um eine möglichst effiziente Softwareentwicklung und Implementierung zu erreichen.

Nach nun zwei Jahren hat C-mol inzwischen einige wissenschaftliche Erfolge zu verzeichnen. Zu denen gehören u.a. ein erster Platz bei Jugend forscht (regional) sowie ein dritter Platz landesweit, die Auszeichnung mit dem Hasso-Plattner-Preis für Softwaresystemtechnik (Potsdam) und diverse Vorträge z.B. beim diesjährigen fachwissenschaftlichen Kongress "Informatiktage" der Gesellschaft für Informatik (http://www.informatiktage.de) und an verschiedenen Hochschulen in Deutschland.

Auf dem offiziellen Portal für methodenorientierte Softwareentwicklung http://www.mosd.net finden Sie alle aktuellen Informationen. Der C-mol Compiler steht dort im C-mol Bereich zum Download bereit oder über die offizielle C-mol Website http://c-mol.mosd.net.
*

Weiterhin:

http://www.c-plusplus.net/php/mylinks/index.php3?count=http%3A%2F%2Fwww.mosd.net

Eventuell gibt's dort ja ein paar geistige Anregungen...

Da gibt's sofort geistige Anregungen - frag besser nicht welche... :xmas2:

Helium

Ich werd's mir auf jeden Fall mal ansehen. Aber der Name ist schonmal gut.

Hat man sich denn mittlerweile mal entschieden, wie weiter programmiert wird?
Ich hab nämlich keine Lust und Zeit mehr jeweils den neuesten Nonplusultra-Entwicklungen hinterher zu laufen, bloss um sie zwei Jahre später wieder als nutzlos und Fehlentwicklung in den Mülleimer zu werfen.
(Methodenorientiert - erm - die Dinge nannte man mal Funktionen - und - erm - Programmierung mit Funktionen ist ja nun nichts Neues...)
Kann es sein, dass sich die Herren Vordenker im Kreis drehen?
Wie wäre es mit isomorpher Programmierung? Da kann man machen, was man will, es kommt sowieso immer auf's Gleiche raus...

Gregor

Ich habe die Dokumentation jetzt mal überflogen und denke, das Grundprinzip verstanden zu haben. Ich sehe aber nichts gutes an MOP, zumindest sehe ich nicht, wo das nützlich sein kann.

Kann sich einer von euch vorstellen, wo das etwas bringt? Was wäre ein typisches Anwendungsbeispiel, in dem MOP anderen Programmierparadigmen überlegen ist?

SendKey

@Bitsy:
In der Tat ist das ewige Hin und Her was neue Softwareentwicklungskonzepte angeht problematisch. Allerdings schmeißt die methodenorientierte Softwareentwicklung nicht alles über den Haufen: Sie arbeitet sogar Hand in Hand mit den objektorientierten Konzepten. Ein Programm kann natürlich rein methodenorientiert entwickelt werden; allerdings ist es ebenso möglich nur ein einzelnes Modul eines sonst objektorientierten Programms methodenorientiert zu entwickeln oder zu erweitern.

Natürlich hat das Denken in "Tätigkeiten" einiges mit strukturierter oder funktionaler Programmierung gemein. Allerdings unterstützt die MOP alle modernen Konzepte wie Codewiederverwendung (durch Vererbung), Polymorphismus, etc. So ist es zum Beispiel möglich von einer oder meheren Methoden zu erben, in dem man sie zu einer Integralmehtode aufleitet. Auch Konzepte zur Vermeidung von redundanten Implementierungen (wie Prolog u. Epilog) finden sich in älteren Ansätzen nicht.

@Gregor:
Die MOP ist vor allem ausgelegt auf Codeeinsparung durch Vermeidung redundanter Implementierungen und starke Modularisierung durch Zentralisierung semantisch gleichartiger Codefragmente. Dies kann nicht nur Entwicklungszeit verkürzen, sondern wirkt sich auch positiv auf die Codewartung aus.

Hab selbst einige Projekte in C-mol realisiert, falls also Fragen bestehen und ich helfen kann, stehe ich gerne zur Verfügung!

Gregor

Mir ist nicht klar, wie man durch MOP Redundanz beseitigen kann, die nicht auch durch andere Techniken leicht beseitigt werden könnte. Hast du dafür mal ein Beispiel?

Helium

Mir ist nicht klar, wie man durch MOP Redundanz beseitigen kann, die nicht auch durch andere Techniken leicht beseitigt werden könnte. Hast du dafür mal ein Beispiel?

Das ist mir auch noch nicht so ganz klar.

Das ganze lässt sich auf jeden Fall recht leicht simulieren:

Auf jeden Fall ist das Grundprinzip sehr leicht zu simulieren. Eigentlich ein Kinderspiel. Nur ist die Synthax natürlich bei weitem nicht so schön.

#include <iostream>
#include <string>

using namespace std;

class Flaeche {
public:
   virtual ~Flaeche()
   {}

   void zeichne ()
   {
      cout << "Zeiche eine Flaeche\n";
   }

};

class Rechteck : public Flaeche {
public:
   void zeichne ()
   {
      cout << "Zeiche ein Rechteck\n";
   }
};

class Kreis : public Flaeche {
public:
   void zeichne ()
   {
      cout << "Zeiche einen Kreis\n";
   }
};

class Fenster {
public:
   virtual ~Fenster ()
   {}

   void zeichne ()
   {
      cout << "Zeichne ein Fenster\n";
   }
};

namespace Zeichne_Objekt { // method Zeichne_Objekt

   // Parameter an Zeichne_Objekt
   string beispiel_parameter; 

   void uebergebe_Methodenparameter (const string & wert)
   {
      beispiel_parameter = wert;
   }

   // eigentlicher Teil

   void prolog () // Zeichne_Objekt ()
   {
      cout << "{\n";
      cout << "der Methodenparameter lautet: " << beispiel_parameter << '\n';
   }
   void epilog () // ~Zeichne_Objekt ()
   {
      cout << "}\n";
   }

   void handling (Rechteck * that) // void <Rechteck *> ()
   {
      cout << "Behandle ein Rechteck\n";
      that->zeichne ();
   }
   void handling (Kreis * that) // void <Kreis *> ()
   {
      cout << "Behandle einen Kreis\n";
      that->zeichne ();
   }   
   void handling (Flaeche * that) // void <Flaeche *> ()
   {
      cout << "Behandle eine Flaeche\n";
      that->zeichne ();
   }
   void handling (Fenster * that) // void <Fenster *> ()
   {
      cout << "Behandle ein Fenster\n";
      that->zeichne ();
   }

   template <typename T>
   void waehle_Handling (T * objekt) // normalerweise unsichtbar
   {
      prolog ();

      try {
         if (typeid(*objekt) == typeid (Rechteck)) {
            handling (dynamic_cast<Rechteck *>(objekt));
         }
         else if (typeid(*objekt) == typeid (Kreis)) {
            handling (dynamic_cast<Kreis *>(objekt));
         }
         else if (typeid(*objekt) == typeid (Flaeche)) {
            handling (dynamic_cast<Flaeche *>(objekt));
         }
         else if (typeid(*objekt) == typeid (Fenster)) {
            handling (dynamic_cast<Fenster *>(objekt));
         }
         else {
            throw ("No such polymorphic handling"); // Das Original wirft auch so!?!
         }
      }
      catch (...) {
         epilog ();
         throw;
      }

      epilog ();
   }

}

int main(int argc, char *argv[]) // ein paar Tests
{
   Flaeche * objekt = new Kreis;
   // Zeichne_Objekt("erster Aufruf")°objekt();
   Zeichne_Objekt::uebergebe_Methodenparameter ("erster Aufruf");
   Zeichne_Objekt::waehle_Handling (objekt);
   delete objekt;

   objekt = new Flaeche;
   // Zeichne_Objekt("zweiter Aufruf")°objekt();
   Zeichne_Objekt::uebergebe_Methodenparameter ("zweiter Aufruf");
   Zeichne_Objekt::waehle_Handling (objekt);
   delete objekt;

   objekt = new Rechteck;
   // Zeichne_Objekt("dritter Aufruf")°objekt();
   Zeichne_Objekt::uebergebe_Methodenparameter ("dritter Aufruf");
   Zeichne_Objekt::waehle_Handling (objekt);
   delete objekt;

   Fenster fenster;
   // Zeichne_Objekt("vierter Aufruf")°objekt();
   Zeichne_Objekt::uebergebe_Methodenparameter ("vierter Aufruf");
   Zeichne_Objekt::waehle_Handling (&fenster);
}

ChrisM

Hi,

klar kannst du es mit C++ "emulieren", aber wenn du es so willst, kannst du auch OOP mit C "emulieren".

Trotzdem versteh' ich auch nicht, was das methodenorientierte Programmieren bringen soll. Zumindest kann ich mich selbst einschätzen und weiß, dass der Vorteil für mich zu klein ist, um umzudenken.

ChrisM

Helium

Allerdings ist der Aufwand, um OO in C zu simulieren ziemlich groß, wogegen sich der Aufwand hier ziemlich in grenzn hält.

Man muss nurnoch einen Weg finden 'waehle_Handling' allgemeiner zu schreiben.

SendKey

Ja, es ist natürlich richtig, dass man C-mol Code mit C/C++ nachbilden kann, so wie man auch C++ mit C nachbilden kann. Das Beispiel von Helium zeigt dies gut.
Was man jedoch bei gut les- und wartbaren Programmen erreichen will ist möglichst eine Trennung zwischen der "technischen" und der "semantischen" Programmierung. So ermöglicht C++ das Denken in Klassen und Objekten ohne dass man sich mit deren technischer Umsetzung im Code befassen muss: Klassen und Objekte lassen sich aus dem "realen Problem" direkt im Code abbilden, wodurch besser lesbarer Code entsteht. (Letztlich übersetzt der Compiler dann den objektorientierten Code in "strukturierten" Maschinencode.)

Im Prinzip ist das bei C-mol und den methodenorientierten Konzepten nicht anders: Man spart sich das technische "Drummherum" und ersetzt es durch eine schönere und übersichtlichere Syntax.
Durch das Denken in Methoden entstehen implizit die Vorteile der Redundanzfreien und zentralen Implementierung, so wie beispielsweise durch das Implementieren virtueller Methoden in C++ implizit der Vorteil des automatischen Ausführens der gewünschten Methode entsteht.
Die Vorteile sollten ja immer aus der Entwicklungsstrategie entstehen, ohne dass man ihnen durch besondere Aufmerksamkeit "nachlaufen" muss, so dass man sich während der Entwicklung auf das wesentliche konzentrieren kann: nämlich eine integere Umsetzung des geplanten Softwareprojektes.

@Helium:
Ich denke, dass man beim Nachbilden der methodenorientierten Konzepte an die Grenzen stößt, wenn man in etwas größeren Projekten mit Methodenvererbung arbeitet und sich die Vorteile von Prolog und Epilog auf immer höheren Abstraktionsebenen zu nutze macht.

@ChrisM:
Umdenken ist natürlich nie einfach, das stimmt. Jedoch macht es C-mol den C++ Programmierern denke ich verhältnismäßig einfach: Man muss ja in dem Sinne keine neue Sprache erlernen. Alle C-mol Konstrukte sind eigentlich eine 1 zu 1 Abbildung der zugehörigen C++ Konstrukte: So entspricht z.B. das Aufleiten von Methoden dem Ableiten von Klassen, virtuelle Handlings entsprechen virtuellen Methoden, etc. Es gelten dafür auch (fast) identische Regeln.

Shade Of Mine

@Sendkey: bitte ein Beispiel - auch wenns etwas länger werden sollte. denn ich verstehe momentan auch den vorteil nicht... danke!

Ich war eigentlich schon immer der Meinung, dass wir am einfachsten zurechtkommen, wenn wir unsere eigene Sprache erstmal anschauen.
Die ist grundlegend mit einem einfachen Hauptsatz des Typs Subjekt Prädikat Objekt ausgestattet. Das verbindende Element ist dabei das Prädikat.
Dem Verb kommt dabei die eigentliche 'Arbeit' zu.

Als Beispiel:
Wenn ich einen String habe und eine Datei in der OOP, erkläre ich dann dem String, wie er sich in die Datei schreiben soll, oder der Datei, wie sie einen String aufnehmen soll? Der Ansatz ist klar und wird über den Stream gelöst.
Nur, dieses Konzept der 'Objektualisierung' eines Verbs hätte man mal zur Hauptsache machen müssen. Denn dann wäre man mit XML weiter, indem dem Objekt wirklich nur noch Attribute zugeordnet werden, wobei die Methodensammlung (in diesem Beispiel der Stream) nur noch ständig erweitert wird - und eigentlich in jeder Sprache realisiert werden kann. Alles bleibt backwards kompatibel und ist aufnahmefähig für alles, was in der Zukunft liegt. Keine Arbeit müsste mehr doppelt gemacht werden. Warum checkt das keiner?

Helium

Mit Aufleitungen muss ich erstmal etwas rumexperimentieren. Villeicht ist es ja wirklich sinnvoll.

Wenn ich das richtig verstanden habe kann man so auf bequeme Art und weise Multidispatcher schreiben:

method Differenzflaeche () {
   virtual int <Rechteck, Rechteck> ()
   { ... }
   virtual int <Rechteck, Kreis> ()
   { ... }
   virtual int <Kreis, Kreis> ()
   { ... }
   ...
};

Ich bräuchte aber auf jeden Fall praxisorientierte Beispiele.

Die MOP ist vor allem ausgelegt auf Codeeinsparung durch Vermeidung redundanter Implementierungen und starke Modularisierung durch Zentralisierung semantisch gleichartiger Codefragmente. Dies kann nicht nur Entwicklungszeit verkürzen, sondern wirkt sich auch positiv auf die Codewartung aus.

Was bedeutet "starke Modularisierung durch Zentralisierung semantisch gleichartiger Codefragmente".

Und die Methodenorientierung schein sich erst bei komplexen Aufgaben zu lohnen. Denn bei einfachen:

method Foo {
   void <Typ1> ()
   {
       // blabla
   }
   void <Typ2> ()
   {
       // blabla
   }
}

// vs.

void bar (Typ1 & that)
{

}

void bar (Typ2 & that)
{

}

Typ1 objekt;

Foo()°objekt(); // Methode

bar (objekt);   // Herkömmliche Funktion

SendKey

Hier nun ein Beispiel, was aus einem C-mol Projekt stammt. Es handelt sich dabei um eine Produktionssimulation, in welcher ein Verteilungsproblem einer laufenden Produktion entnommener Proben auf verschiedene Analysegeräte durch ein Agentensystem gelöst werden soll.
Ich habe hier die Analyse-Methode ausgesucht, die einen Prolog, einen Epilog und zwei Handlings, darunter ein Multihandling für zwei verschiedene Analysegeräte implementiert.

Hier die Headerdatei "Analysiere.hmol":

C-mol Code:

#if !defined Analysiere_hmol
	#define Analysiere_hmol

#include "Geraet.h"
#include "Probe.h"

method MAnalysiere( CProbe& Probe )
{
	MAnalysiere();
	~MAnalysiere();
	virtual void <CGeraet1*, CGeraet2*>();
	virtual void <CGeraet3*>();
};

#endif

Hier die zugehörige Implementierungsdatei "Analysiere.cmol":

C-mol Code:

#include <typeinfo>
#include <fstream.h>
#include <string.h>

#pragma c-mol_hdrstop

#include "Analysiere.hmol"
#include "Speichere.hmol"
#include "Geraet.h"
#include "Produktion.h"

using namespace std; 

extern CProduktion Produktion; 

// Prolog
MAnalysiere::MAnalysiere()
{
	Probe.Status = CProbe::EStatus::STAT_INBEARBEITUNG;
}

// Epilog
MAnalysiere::~MAnalysiere()
{

	// Wenn die Analyse eines Geraets abgeschlossen ist, dann Speichere und setze den Fertig-Status
	if( Probe.Status != CProbe::EStatus::STAT_INBEARBEITUNG )
	{

		// Speichere Protokoll
		delete [] Probe.GeraeteListe[ 0 ]->sProtokoll; 
		Probe.GeraeteListe[ 0 ]->sProtokoll = new char[ strlen( Probe.ProbeDaten() )+strlen( " analysiert" )+1 ];
		strcpy( Probe.GeraeteListe[ 0 ]->sProtokoll, Probe.ProbeDaten() ); 
		strcat( Probe.GeraeteListe[ 0 ]->sProtokoll, " analysiert" ); 
		MSpeichere( Probe )°( Probe.GeraeteListe[ 0 ] )();

		// Gerät aus Liste dieser Probe löschen
		Probe.GeraeteListe.Remove( 0 );
		Probe.AktuellesGeraetNr = 0;   // Steht für KEIN Geraet, da keins mit Nr. 0 gibt

		// Wenn dies nicht das letzte Gerät der Probe war
		if( Probe.GeraeteListe.NrOfElements() > 0 )
			Probe.Status = CProbe::EStatus::STAT_AUFDEMWEG;
		else
			Probe.Status = CProbe::EStatus::STAT_FERTIG; 
	}
}

// Multihandling
void MAnalysiere::<CGeraet1*, CGeraet2*>()
{
// Analyseroutine von Geraetetyp 1 und 2 sind identisch, daher Multihandling!
}

// Normales Handling
void MAnalysiere::<CGeraet3*>()
{
// Analyseroutine von Geraetetyp 3 unterscheidet sich von den anderen, daher eigenes Handling!
}

Bei einer reinen C++ Lösung hätte man hier vermutlich eine abstrakte Analyse-Methode in der Basisklasse für die Geräte, die dann von allen abgeleiteten Geräten implementiert werden würde. Dabei müsste man in diesem Fall den Prolog und Epilog in jeder dieser Routinen implementieren sowie die für Gerät 1 und 2 identische Implementierung ebenfalls doppelt implementieren.
Außerdem ergeben sich weitere Vorteile für die Codewartung und Programmerweiterung:
Soll beispielsweise ein weiteres Gerät ergänzt werden, welches eine bereits implementierte Analyse-Methode benötigt, so reicht es dieses einfach in der entsprechenden Handlingidentifikation mit aufzuführen. Veränderungen die für alle Geräte gelten sollen können zentral an einer Stelle im Code, z.B. im Prolog vorgenommen werden.

Korbinian

mal schauen, ob ich das programm verstanden hab. hier mal eine shortened version in c++:

void Epilog()
{
    // blablablub
}

void Prolog()
{
    // blablablub
}

/* Einzige aenderung: Geraet1 und Geraet2 werden von der gleichen basisklasse abgeleitet, 
die die gleichen members haben. müssen die gleichen sein, sonst würde der code ja nicht fuer beide hinhauen */

void EigentlicheFunktion(Geraet1_2Base *g)
{
    Prolog();
    // blablablubb
    Epilog();
}

void EigentlicheFunktion(Geraet3 *g)
{
    Prolog();
    // blabla
    Epilog();
}

hab ich das richtig verstanden? wenn ja: wo is der mehraufwand, der eine spracherweiterung sinnvoll macht? man kann die EigentlicheFunktion mit Geraet1, 2 oder 3 aufrufen, und es wird genau die richtige funktion ausgewertet. nix doppelt.

Cortex

Da faellt mir so direkt ein:

1. Du musst alle Klassen, wie du selbst gesagt hast, von einer Basisklasse ableiten. Was ist aber z.B. wenn du Klassen aus einer Bibliothek verwendest? Mit C-mol kannst du in diesem Fall einfach ein Handling auf z.B. <string*, AnsiString*> definieren, die beide gleichlautende Funktionen besitzen.

2. Sicherlich eher seltener, aber: Vielleicht moechte ich gar keine Funktion dieser Objekte aufrufen, sondern sie z.B. nur durchreichen. Da kann dann ein Multihandling sogar schon Sinn machen, ohne dass die Objekte verwandte Funktionen besitzen.

3. Du musst immer daran denken, den Prolog und den Epilog aufzurufen. Dass muss wieder dokumentiert und/oder allen Teamkollegen erklaert werden. Wenn's einer vergisst, geht die Fehlersuche los...
In der MOP hingegen: Neues Handling wird ergaenzt, nur spezifischer Code wird geschrieben, alles andere geht automatisch. Der Aufruf des Initialisierungs- und Finalisierungscodes in Prolog und Epilog kann nicht unterlassen werden.

4. Im Uebrigen: die MOP verhindert deine Loesung ja nicht! Selbstverstaendlich kannst du auch einfach ein Handling fuer die Basisklasse definieren. Damit kann die Methodenorientierung an anderen Stellen verwendet werden und an dieser Stelle wird trotzdem die deiner Meinung nach effizienteste und sauberste Loesung verwendet werden.

Aber Multihandlings und Prolog/Epilog sind ja nicht die einzigen Konzepte, die durch die MOP ermoeglicht werden. Da waeren z.B. auch noch Aufleitung, erweiterter Polymorphismus, Method-Chains und das bedeutendste Element, die verbesserte Lesbarkeit des Codes in vielen Situationen...

virtuell Realisticer

Ich denke, dass man nicht sagen kann, wann das eine besser oder schlechter ist,
solange man nicht ein groesseres Projekt hat.

Man koennte jetzt bestimmt tausende von kleinen Fallbeispielen konstruieren,
was wahrscheinlich aber an der Realitaet vorbei geht.

Cortex schrieb:

...
und das bedeutendste Element, die verbesserte Lesbarkeit des Codes in vielen Situationen...

Sorry, aber das Argument lass ich bei mir schon lange nicht mehr ziehn. Bin mir
ziehmlich sicher, dass man mit C-Mol richtigen Schweinecode schreiben kann, so
wie es C/C++ auch moeglich ist. Genauso gut ist es in jeder x-beliebigen Sprache
moeglich Code zu schreiben, den kein Mensch lesen kann.

mfg
v R

Cortex

virtuell Realisticer schrieb:

Ich denke, dass man nicht sagen kann, wann das eine besser oder schlechter ist, solange man nicht ein groesseres Projekt hat.

Um diese besser/schlechter-fuer-grosse/kleine-Projekte-Diskussion erst gar nicht aufkommen zu lassen, ist C-mol ja eine Sprach*erweiterung* zu C++. Du kannst eben 99% in C++ schreiben und das eine Prozent, dass in diesem speziellen Projekt Sinn macht, mit den erweiterten Moeglichkeiten von C-mol. Man muss sich niemals entscheiden.

virtuell Realisticer schrieb:

Bin mir ziemlich sicher, dass man mit C-Mol richtigen Schweinecode schreiben kann, so
wie es C/C++ auch moeglich ist. Genauso gut ist es in jeder x-beliebigen Sprache
moeglich Code zu schreiben, den kein Mensch lesen kann.

Natuerlich, aber es geht ja nicht darum, moeglichst 'schlechten' Code, sondern moeglichst 'guten' Code zu schreiben. Und dafuer lassen sich in C-mol einige Dinge besser ausdruecken als in C++ (wie auch umgekehrt!). Wer sich nicht auf die neuen Konzepte einlaesst, wird mit C-mol sicherlich nicht von heute auf morgen besseren Code schreiben. Aber bei konsequenter Nutzung der neuen Moeglichkeiten an den richtigen Stellen wird man schon zu etwas besserem Code 'erzogen'. Ausserdem tragen die bereits beschriebenen Zusammenfassungen und Reduktionen natuerlich schon zu lesbarerem Code bei.

Gregor

Wenn ich das richtig verstanden habe, dann soll MOP ja besonders dann etwas bringen, wenn man wenige, semantisch gleiche Dinge mit vielen unterschiedlichen Arten von Objekten macht, wobei sich die Objekte selbst möglichst stark semantisch von einander unterscheiden.

1. Ist das richtig?
2. Wo kommt soetwas vor?