was ich vor habe ist folgendes:

ich habe verschiedene Algorithmen zum verschluesseln, Hash generienern und zum Encoden. Jetzt moechte ich einen Layer erstellen der alles bereit stellt und auch waehrend der Laufzeit dynamisch erweitert werden kann.

Ich hab mir das so vorgestellt das es z.B. eine Funktion gitb mit der man einen Algorithmus registrieren kann mit Name + Funktion die eine solche Klasse erstellt. Desweiteren gibt es eine Funktion "GetCrypter" z.B. die dann den Namen des benoetigten Crypter braucht und dann ein Objekt davon erzeugt.

Waere das von der Theorie her ok? Und wenn ja was is das dann fuer ein Pattern (Builder, factory..)

Hier hab ich jetzt noch versucht ein kleines UML Diagramm zu erstellen (muss sagen is schon laenger her das wir das in der Schule gemacht habe)

+-----------------------------------+
|  SecurityLayer   				|
|  -------------					|
| + RegisterCrypter				|
| + RegisterHash					|
| + ...							|
| + GetCrypter: Crypter			|
| + ....							|
+-----------------------------------+

+-----------------------------------+
|  Crypter (abstract)				|
|  -------------					|
| +Encrypt=0						|
| +Decrypt	=0						|
| + GetName		=0					|
+-----------------------------------*
			^
			|
			|
+-----------------------------------+
|  XOR								|
|  -------------					|
| methoden implementieren			|
+-----------------------------------+

Was auch noch schoen waere wenn einer Links mit guten Erklaerungen + C++ Beispile fuer die einzelnen Pattern haette.

Greetz C0de4Fun

Die Aufgabe klingt nach dem Strategy Pattern. Siehe z. B. im Magazin. Du kannst den Crypter auch als Template-Parameter übergeben, wenn er sich für eine Instanz nicht ändert. Das läuft dann unter dem Namen Policy-based Design.

Danke schon mal.
Ich hab mir des jetzt mal angeschaut,
Zum Strategy Pattern: also so wie ich des verstanden habe passt das nicht so richtig, da ich ja ein Layer zur verfuegung stellen will der halt verschiedene Algorithmen (Verschluesselung, Hash, Encoding) beinhaltet. Dieser soll schon ein paar beinhalten wie z.B. XOR, base64 und MD5. Dieser Layer soll in einem Programm zur verfuegung gestellt werden der Hauptsaechlich ueber Plug-Ins gesteuert wird. Und diese sollen z.B. auch neue Verschluesselungen registrieren koennen mit dennen dann alle arbeiten koennen.

Und beim Strategy Pattern hab ich doch eine Instanz einer Klasse(zB. Crypter::XOR) die ich dann einer anderen Klasse(z.B. FileManager Plugin) uebergebe und die mit dieser arbeitet

Und zum Policy-baded Design: ist eig au schlecht da ich den Plugins die Moelgichkeit zur verfuegung stellen will, entweder aus den verschiedenen Arten auszuwaehlen oder halt verschiedene Algorithmen fuer verschiedene Aufgaben verwenden lassen will.

Hmm ich hoffe es kommt alles rueber was ich machen moechte.

Greetz C0de4Fun

Ich zeig dir ein Beispiel, das du schon kennst. Das ist die Deklaration von std::vector:

template < class T, class Allocator = allocator<T> > class vector;

Was du vorhast, geht analog zum Allocator-Template-Parameter. Der std::vector braucht eine Strategie, um Speicher anfordern zu können. Um diese Wahl dem Nutzer zu überlassen, gibt es dafür einen Template-Parameter. Das Analogon wäre in deinem Fall die Hash-Strategie.

Die Standardbibliothek gibt zudem einen Default-Allokator mit, den der User benutzen kann. Das möchtest du mit ein paar Hash-Algorithmen ebenfalls machen, indem du die entsprechenden Klassen einfach mitlieferst.

So ganz verstehe ich deine Bedenken ehrlich gesagt nicht.

Naja, wenn er das ganze pluginbasiert aufziehen will, aendern sich die möglichen Varianten zur Laufzeit. Bei nem Template muessen die zur compilezeit feststehen.

Ergo, Template und Plugin beissen sich schon bissi in der Beziehung.
Oder überzeug mich vom gegenteil und bau ne vector template implementierung, wo ich den Allokator über nen plugin zur verfuegung stellen kann, das geladen werden kann aber nicht muss, bzw der user beim start des Programms festlegen kann, welcher allokator in allen vectoren verwendet wird, und trotzdem der allokator ueber nen template parameter festgelegt werden soll

Ciao ...

Ergo, Template und Plugin beissen sich schon bissi in der Beziehung.
Oder überzeug mich vom gegenteil und bau ne vector template implementierung, wo ich den Allokator über nen plugin zur verfuegung stellen kann, das geladen werden kann aber nicht muss, bzw der user beim start des Programms festlegen kann, welcher allokator in allen vectoren verwendet wird, und trotzdem der allokator ueber nen template parameter festgelegt werden soll

Easy. Du machst nen allocator der intern eben polymorph den echten allokator verwendet. Deshalb kannst du zB einen allocator beim ctor von vector angeben.

bzw. ist das ganze deshalb illegal weil ein allocator keinen internen state haben darf - aber das ist ein design fehler der library und kein technisches hindernis.

class Crypter;
class Client
{
public:
    void read(Crypter& c);  // strategy
};

Auf der anderen Seite steht die Frage nach der Erzeugung oder Verwaltung der Strategien. Hier ist ein Erzeugungsmuster gefragt. Deine Vorstellung geht denke ich in Richtung Fabrik.

namespace SecurityLayer
{

class CrypterFactory
{
public:
    typedef Crypter* (*Creator)();
    void RegisterCrypter(const std::string& name, Creator f);
    Crypter* CreateCrypter(const std::string& name);
};

// oder Erzeugung mit Prototype Pattern
class CrypterRepository
{
public:
    void RegisterCrypter(const std::string& name, Crypter* prototype);
    Crypter* CreateCrypter(const std::string& name);
};

}

Alle Fabriken für Crypt, Hash usw. in einer Klasse SecurityLayer zu sammeln halte ich für sinnlos. Sieht nach Ordnungswahn aus, "toll, ich habe alles an einer Stelle". So eine Bündelung von Abhängigkeiten ist aber gerade zu vermeiden. Mach aus Klasse einen Namensraum um die Zusammengehörigkeit in einem Layer aufzuzeigen. Anders sieht es aus, wenn SecurityLayer eine abstrakte Fabrik darstellt, die austauschbar ist und jeweils zusammengehörende Strategien erzeugt.

class Hasher;
class AbstractSecurityFactory
{
public:
    virtual Crypter* CreateCrypter() = 0;
    virtual Hasher* CreateHasher() = 0;
};

class ABCSecurityFactory : public AbstractSecurityFactory
{
public:
    ABCCrypter* CreateCrypter();
    ABCHasher* CreateHasher();
};
class XYZSecurityFactory : public AbstractSecurityFactory
{/*..*/};

class Client
{
public:
    void ChangeSecurity(AbstractSecurityFactory&);
};

http://de.wikipedia.org/wiki/Abstrakte_Fabrik

class IDataSink
{
   ...
   virtual void write( char* Data, unsigned int Size ) = 0;
   ...
};

class FileDataSink : public IDataSink
{
   // Daten in Datei schreiben
   void write( const char* Data, unsigned int Size );
};

class MemoryDataSink : public IDataSink
{
   // Daten in Puffer (Hauptspeicher) schreiben
   void write( const char* Data, unsigned int Size );
};

class HashDataSinkDecorator
{
   IDataSink& DataSink_;

   HashDataSinkDecorator( IDataSink& Sink ) :
      DataSink_( Sink )
   {
   }

   void write( char* Data, unsigned int Size )
   {
      // aus Daten Hash berechnen und Hash schreiben
      DataSink_.write( Hash, HashSize );
   }
};

int main()
{
   string s = "Hello World";

   // File Sink zum Schreiben in Datei
   FileSink FS( "c:/hash.dat" );

   // Hash Sink zum Erzeugen eines Hashes
   HashDataSink HS( FS );
   HS.write( s.c_str(), s.size() );
}

@brotbernd:

ich hab jetzt das hier geschrieben:

namespace security
{

template <class T>
class SecurityFactory
{
public:
	typedef T* (*GetInstance) ();
	typedef std::map<std::string, GetInstance>  AlgorithmMap;

	SecurityFactory(void) {};
	~SecurityFactory(void) {};

	bool AddAlgorithm(const std::string& Name, GetInstance pfGetInstance)
	{
		if( AlgorithmExist(Name) )
			return false;

		m_AlgorithmMap[ Name ] = pfGetInstance;
		return true;
	}
	void RemoveAlgorithm(const std::string& Name)
	{
		AlgorithmMap::iterator iter = m_AlgorithmMap.find( Name );

		if( iter != m_AlgorithmMap.end() )
			m_AlgorithmMap.erase( iter);
	}
	bool AlgorithmExist(std::string Name)
	{
		return (m_AlgorithmMap.find( Name) != m_AlgorithmMap.end() ) ? true : false;
	}

	T* Create(const std::string& Name)
	{
		if( AlgorithmExist(Name) )
			return m_AlgorithmMap[Name]();
		return NULL;
	}

private:

	AlgorithmMap m_AlgorithmMap;
};

}

Seh ich das richtig so?
Und dann einfach drei verschiedene Factories erstellen:

security::SecurityFactory<security::encode::Encoder> EncoderFactory;
security::SecurityFactory<security::hash::Hash> HashFactory;
security::SecurityFactory<security::crypt::Crypter> CrypterFactory;

Greetz C0de4Fun

template <class T>
class AbstractFactory
{
public:
    virtual T* CreateInstance() = 0;
};

class XxxFactoryDings
{
// ...

    void RegisterFactory(const std::string& Name, AbstractFactory<Foo>* fooFactory);

// ...
};

Zwei andere Dinge die mit der Factory-Sache nix mehr zu tun haben und auch entschieden Ansichtssache sind: ich würde Smart-Pointer verwenden, und ich würde in den beiden Fällen "Factory mit dem Namen ist bereits registriert" und "kann Objekt nicht erzeugt werden weil Factory mit dem Namen nicht bekannt" Exceptions werfen antatt false bzw. nen NULL Pointer zurückzugeben.

Ich würde statt einem Funktionszeiger einen Zeiger auf eine abstrakte Factory-Klasse registrieren.
Also

template <class T>
class AbstractFactory
{
public:
    virtual T* CreateInstance() = 0;
};

class XxxFactoryDings
{
// ...

    void RegisterFactory(const std::string& Name, AbstractFactory<Foo>* fooFactory);

// ...
};

Meinste dann ca so:

template<class T>
class AbstractFactory
{
public:
	virtual T* Create() = 0;

};

class StrFactory : public AbstractFactory<std::string>
{
public:
	virtual std::string* Create() { return new std::string("test"); };
};

int main(int argc, char** argv)
{
	std::vector< AbstractFactory<std::string>* > Vector;
	StrFactory StrFac;

	Vector.push_back( &StrFac);

	std::cout << (Vector[0]->Create())->c_str()  << std::endl;

    return 0;
}

Und wo ist da der Vorteil gegenueber einer Create Funktion? Seh ich leider ned ganz.

hustbaer schrieb:

Zwei andere Dinge die mit der Factory-Sache nix mehr zu tun haben und auch entschieden Ansichtssache sind: ich würde Smart-Pointer verwenden, und ich würde in den beiden Fällen "Factory mit dem Namen ist bereits registriert" und "kann Objekt nicht erzeugt werden weil Factory mit dem Namen nicht bekannt" Exceptions werfen antatt false bzw. nen NULL Pointer zurückzugeben.

Also das mit den Smart Pointern werd ich mir halt jetzt doch mal anschauen. Hab bis jetzt immer versucht um boost drum rum zu kommen. Da ich denk des wird einige Zeit an einlesen kosten. Aber was solls. Kann ja eig nur Vorteile bringen :).

Und zu den Exceptions: Ich muss sagen ich find des ned so gut. Sagen wir ich lad ein PlugIn das registriert dein MD5 Alogrithmus da es diesen braucht. Jetzt lad ich spaeter ein neues PlugIn dazu das wiederrum auch MD5 benoetigt und das halt auch registrieren will. Jetzt muss er ja immer vorher checken ob der schon vorhanden ist.
Ist doch einfacher so.
Beim "kann kein Objekt erzeugen" find ichs an sich au gut. Mal schauen.

Greetz C0de4Fun

Vorteil: die Factory kann "State" halten. Und das kann aus den verschiedensten Gründen vorteilhaft sein.
Man braucht es in vielen Programmen vielleicht nicht oft (oder gar nicht), aber wenn man es mal bräuchte, und es geht nicht, dann ist es richtig kacke.

Ja, mein ich ca. so.

Vorteil: die Factory kann "State" halten. Und das kann aus den verschiedensten Gründen vorteilhaft sein.
Man braucht es in vielen Programmen vielleicht nicht oft (oder gar nicht), aber wenn man es mal bräuchte, und es geht nicht, dann ist es richtig kacke.

Joa warum dann nicht gleich besser machen des stimmt schon.

Ich hab jetzt mal beides umgesetzt und wollte fragen obste mal nen Blick drueber werfen koenntest:

namespace security
{

template <class T>
class SecurityFactory
{
public:
	typedef AbstractFactory<T> AlgorithmFactory;
	typedef std::map<std::string, AlgorithmFactory*>  AlgorithmMap;
	typedef std::vector<std::string> AlgorithmNameVec;
....
	bool AddAlgorithm(const std::string& Name, AlgorithmFactory* Factory)
	{
		if( AlgorithmExist(Name) )
			return false;

		m_AlgorithmMap[ Name ] = Factory;
		return true;
	}
	....
	boost::shared_ptr<T> Create(const std::string& Name)
	{
		if( AlgorithmExist(Name) )
			return m_AlgorithmMap[Name]->Create();

		throw "Algorithm not found";
	}

private:

	AlgorithmMap m_AlgorithmMap;
};

und dann zB. so:

class HashFac : public AbstractFactory<security::hash::Hash>
{
public:
	boost::shared_ptr< security::hash::Hash> Create()
	{
		boost::shared_ptr< security::hash::Hash> Tmp( new security::hash::MD5 );
		return Tmp; 
	};
};

int main( int argc, char** argv)
{
	HashFac HashTmp;

	boost::shared_ptr<security::hash::Hash> HashPtr;
	security::SecurityFactory<security::hash::Hash> HashFactory;

	std::string test("lol armin stock");

	HashFactory.AddAlgorithm( "md5", &HashTmp);
	HashPtr = HashFactory.Create("md5");

	HashPtr->Update( (const BYTE*)test.c_str(), test.size() );
	HashPtr->Finish( );

	std::cout << HashPtr->Hex() ;

	return 0;
}

In C++0x gibts ausserdem noch Lambda-Ausdrücke.