010
09.04.2005, 20:30 Uhr
Spacelord
Hoffnungsloser Fall
|
Ich mal wieder 
| Zitat von Th: |
Nein, das Problem ist, daß die Basisklasse, sowie die davon abgeleiteten Klassen keinen Zugriff auf die StringRessourcen haben. Es geht darum, daß ich einen lokalisierbaren Namen im Interface für jedes SpaceObjekt anzeigen will - eben in Abhängigkeit des jeweiligen Typs.
|
Ok,ihr habt also aus irgendwelchen Gründen die Entwurfsentscheidung getroffen der Basisklasse kein Wissen über die Stringresource mit auf den Weg zu geben(obwohl es da ja zweifelsohne eine Assoziation gibt).
Aus meiner Sicht ist diese Entscheidung fragwürdig,wenn dann doch in allen Subtypen diese Information nachträglich,unter erheblichen Mehraufwand,hinzugefügt wird!?
Naja,wie dem auch sei.Wenn ich das mal einfach so schlucke und das Entwurfsziel,die Stringresourcen von den konkreten BaseSpaceObject Klassen zu entkoppeln, so hin nehme
dann kommt mir folgende Idee.
Da die Stringresource ja eigentlich eher der Klasse zugeordnet ist,als irgendwelchen Exemplaren der Klasse,wäre es doch möglich die Assoziation zwischen den konkreten BaseSpaceObject Typen und den passenden Stringresourcen über ne std::map zu realisieren.Dabei kann man dann das bißchen an Metainformationen nutzen was C++ so hergibt.
Man könnte dann die lokalen Resourcen in ner std::map<string,string> speichern wobei der Schlüssel dann aus typeid(eine derBaseSpaceObjectKlassen).name() besteht und der zweite Teil des Paares die lokale Bezeichnung der Klasse repräsentiert.
Dann müsste für jede Sprache ne Klasse entworfen werden die in seiner map den Klassen die lokale Bezeichnung zuordnet.
Ich hab mir da jetzt 2 Tage drüber den Kopf zerbrochen aber an der Tatsache dass man für jede neue Subklasse alle maps aktualisieren müsste,und dass man für jede neue Sprache allen Klassen neue lokale Bezeichner geben müsste,lässt sich nichts drehen.An irgendeiner Stelle müssen diese Daten immer angegeben werden,egal für welches Design man sich entscheidet!
Mit den map´s ist es vielleicht etwas schwieriger weil man jedesmal erst noch den Namen des Typs ermitteln muss aber dafür ist das Entwurfsziel erreicht die BaseSpaceObject Klassen total von der Stringresource zu entkoppeln.
Hier ist nochmal nen Beispielcode,wieder minimal....
| C++: |
#include <iostream>
#include <string>
#include <typeinfo>
#include <map>
using namespace std;
//Gruppe der BaseSpaceObject Klassen
class BaseSpaceObject
{
public:
virtual ~BaseSpaceObject(){};
virtual void foo1() = 0;
virtual void foo2() = 0;
};
class Hunter:public BaseSpaceObject
{
public:
virtual void foo1(){cout<<"Hunter::foo1\n";}
virtual void foo2(){cout<<"Hunter::foo2\n";}
};
class Planet:public BaseSpaceObject
{
public:
virtual void foo1(){cout<<"Planet::foo1\n";}
virtual void foo2(){cout<<"Planet::foo2\n";}
};
//Gruppe der Klassen zur Verwaltung der lokalen Sprachresourcen
class LanguageResource
{
public:
virtual ~LanguageResource(){};
virtual const string& getName(const BaseSpaceObject& bso)const
{
return res.find(typeid(bso).name())->second;
}
protected:
map<string,string> res;
};
class EngResource:public LanguageResource
{
public:
EngResource(){initMap();}
protected:
void initMap()
{
res.insert(pair<string,string>((typeid(Hunter)).name(),"Hunter"));
res.insert(pair<string,string>((typeid(Planet)).name(),"Planet"));
}
};
class GerResource:public LanguageResource
{
public:
GerResource(){initMap();}
protected:
void initMap()
{
res.insert(pair<string,string>((typeid(Hunter)).name(),"Jaeger"));
res.insert(pair<string,string>((typeid(Planet)).name(),"Weltraumkugel ;) nur damit ich mich vom englischem unterscheide"));
}
};
class ChiResource:public LanguageResource
{
public:
ChiResource(){initMap();}
protected:
void initMap()
{
res.insert(pair<string,string>((typeid(Hunter)).name(),"WungPungFung"));
res.insert(pair<string,string>((typeid(Planet)).name(),"ChopWokPok"));
}
};
//Aufzählungstyp als Parameter für die Factory
enum Language
{
GER=0,
ENG,
CHI
};
class ResourceFactory
{
public:
ResourceFactory(){};
~ResourceFactory(){};
LanguageResource* createLocalResource(Language l=ENG)
{
switch(l)
{
case ENG:
return new EngResource();
break;
case GER:
return new GerResource();
break;
case CHI:
return new ChiResource();
break;
default:
return NULL;
}
}
};
class LanguageController
{
public:
LanguageController():res(0){setLanguage(ENG);};
virtual ~LanguageController(){if(res)delete res;}
bool setLanguage(Language l)
{
if(res!=NULL)
delete res;
res = rf.createLocalResource(l);
return (res!=NULL);
}
const string& getLocalName(const BaseSpaceObject& o)
{
return res->getName(o);
}
protected:
ResourceFactory rf;
LanguageResource* res;
};
int main()
{
int i;
LanguageController sprache;
BaseSpaceObject* bso[3];
bso[0]= new Hunter();
bso[1]= new Planet();
bso[2]= new Hunter();
for(i=0;i<3;i++)
{
bso[i]->foo1();
cout<<sprache.getLocalName(*bso[i])<<endl;
}
sprache.setLanguage(GER);
for(i=0;i<3;i++)
{
bso[i]->foo1();
cout<<sprache.getLocalName(*bso[i])<<endl;
}
sprache.setLanguage(CHI);
cout<<"\n\nUnd auf Chinesisch:"<<sprache.getLocalName(*bso[0])<<endl;
for(i=0;i<3;i++)
{
delete bso[i];
}
return 0;
}
|
Warscheinlich fehlen wieder irgendwelche Destruktoren aber das Prinzip sollte deutlich werden.Ausserdem hab ich schon einige Bier auf und keinen Bock mich in Details zu verrennen  .
Das ganze ist meiner Meinung nach relativ gut erweiterbar.
Das was aktualisiert werden muss falls ne neue Klasse oder Sprache hinzugefügt wird,muss ohnehin an irgend einer Stelle hinzugefügt werden.
MfG Spacelord
--
.....Ich mach jetzt nämlich mein Jodeldiplom.Dann hab ich endlich was Eigenes.
Dieser Post wurde am 09.04.2005 um 20:31 Uhr von Spacelord editiert. |
