L'usine de la méthode de la mise en œuvre - C++

J'ai le code suivant pour "l'usine" modèle de conception de la mise en œuvre.

class Pen{
public:
     virtual void Draw() = 0;
};

class RedPen : public Pen{
public:
     virtual void Draw(){
         cout << "Drawing with red pen" << endl;
     }
};

class BluePen : public Pen{
public:
     virtual void Draw(){
         cout << "Drawing with blue pen" << endl;
     }
};

auto_ptr<Pen> createPen(const std::string color){
     if(color == "red")
         return auto_ptr<Pen>(new RedPen);
     else if(color == "blue")
         return auto_ptr<Pen>(new BluePen);
}

Mais j'ai entendu qu'il peut être fait dans une meilleure façon, à l'aide de "modèles C++". Quelqu'un peut-il aider à comment il est fait et comment le modèle de l'approche est mieux que cela?

Toutes les pensées

OriginalL'auteur Navaneeth K N | 2009-01-04

  1. 4

    Dans l'exemple que vous avez posté, ni une usine ou d'un modèle de démarche fait sens pour moi.
    Ma solution passe par un membre de données dans le Stylo de classe.

    class Pen {
public:
Pen() : m_color(0,0,0,0) /* the default colour is black */
{            
}
Pen(const Color& c) : m_color(c)
{
}
Pen(const Pen& other) : m_color(other.color())
{
}
virtual void Draw()
{
cout << "Drawing with a pen of color " << m_color.hex();
}
void setColor(const Color& c) { m_color = c; }
const Color& color() const { return m_color; }
private:
Color m_color;
};
class Color {
public:
Color(int r, int g, int b, int a = 0) :
m_red(r), m_green(g), m_blue(other.blue()), m_alpha(a)  
{
}
Color(const Color& other) : 
m_red(other.red()), m_green(other.green()), 
m_blue(other.blue()), m_alpha(other.alpha())
{
}
int red() const { return m_red; }
int green() const  { return m_green; }
int blue() const { return m_blue; }
int alpha() const { return m_alpha; }
std::string hex() const
{
std::ostringstream os;
char buf[3];
os << "#";
sprintf(buf, "%2X", red());
os << buf;
sprintf(buf, "%2X", green());
os << buf;
sprintf(buf, "%2X", blue());
os << buf;
sprintf(buf, "%2X", alpha());
os << buf;
return os.str();
}
private:
int m_red;
int m_green;
int m_blue;
int m_alpha;
}

    Bien sûr, la couleur de la classe devra être ajusté à l'API de dessin vous utilisez -- et peut-être de façon plus avancé que celui-ci (différents espaces de couleurs, etc).

    Pourquoi pas des modèles?

    La raison pour laquelle il n'a pas de sens d'utiliser des modèles, est (vraisemblablement) la seule différence entre les différentes opérations de dessin est de couleur variable. Donc, à l'aide de modèles (ou manuellement déclarant différentes classes, comme vous l'avez fait), vous devez dupliquer le même code. Cela permettra à votre programme de grand, et de le ralentir.

    Donc, le tirage au sort de la fonction doit prendre la couleur comme un argument, ou (comme dans mon exemple) ont la couleur en tant que données de la classe membre.

    Quel est le point de la copie par référence constructeur dans votre code ici ?
    Qui a appelé à un constructeur de copie, et seront appelés à la fois surprenant. Comme le code est écrit, il n'y a aucun point important, autre que de dire que quand je copie un stylo, ce que je fais c'est que je copie la couleur de la plume. Si Color était plus complexe, cela pourrait avoir de compte beaucoup plus.

    OriginalL'auteur gnud

  2. 11

    Une autre façon est d'enregistrer dynamiquement un créateur fonction d'une dynamique de l'Usine de l'objet.

    BluePen *create_BluePen() { return new BluePen; }
static bool BluePen_creator_registered = 
Factory::instance()->registerCreator("BluePen", 
create_BluePen);

    Un effet intéressant en faisant comme ceci, c'est que la variable static bool BluePen-creator-registered sera mis en avant main() commence donc de faire de l'enregistrement automatisé.

    Ces lignes sont parfois faites par ordinaire des macros, c'est à dire que

    #define METAIMPL( _name ) \
_name *create_ ## _name() { return new _name; } \
static bool _name ## _creator_registered = \
Factory::instance()->registerCreator(# _name, \
create_ ## _name)

    ...et près du constructeur

    METAIMPL( BluePen ); //auto registers to the Factory
BluePen::BluePen() : Pen() {
//something
}

    Puis l'Usine tâche sera de stocker et de recherche de ces créateur fonctions. Je laisse le reste comme l'exercice 😉 c'est à dire l'utilisation d'un METADECL macro

    Si vous voulez plus d'info, voir ici en vertu du chapitre 4.1 les Méta-Informations qui comprend également une méthode pour élargir pour inclure les possibilités de inspecteur caractéristiques

    J'ai appris cela grâce à l'aide de ET++ c'était un projet de port vieux MacApp C++ et X11. Dans l'effort de Eric Gamma etc commencé à penser à Modèles de Conception

    Et...(7 Mai 2011) est Enfin de pousser un exemple de github
    https://github.com/epatel/cpp-factory

    J'ai une autre DONC, la question au sujet de cette réponse: stackoverflow.com/questions/3770654/... Toute chance vous pourriez avoir un coup d'oeil? Merci à l'avance.

    OriginalL'auteur epatel

  3. 5

    Votre usine est très bien. - Je prendre de la BluePen et ainsi de suite étaient que des exemples, des noms de classe. Vous pouvez utiliser des modèles, si la condition suivante est satisfaite:

    Quand vous savez au moment de la compilation (j'.e lorsque vous écrivez du code) que vous voulez un type spécifique retourné, puis d'utiliser un modèle. Sinon, vous ne pouvez pas.

    Cela signifie que dans le code, que vous pouvez faire ceci:

    template<typename PenType>
auto_ptr<Pen> createPen(){
return auto_ptr<Pen>(new PenType);
}

    Avoir à la place, vous pouvez ensuite l'utiliser comme

    ...
auto_ptr<Pen> p = createPen<BluePen>();
...

    Mais ce modèle-argument, la BluePen, ne peut pas être une variable qui est définie pour un type à l'exécution. Dans votre exemple, vous passez une chaîne de caractères, qui peut bien sûr être réglé au moment de l'exécution. Donc, quand vous lisez que vous pouvez utiliser les Modèles C++, alors que la recommandation est que conditionnellement vrai - puis, lorsque votre décision, qui stylo à créer, est déjà fait au moment de la compilation. Si cette condition répond, puis le modèle de solution est la bonne chose à faire. Il ne vous coûtera rien, au moment de l'exécution, et sera exactement ce dont vous avez besoin.

    OriginalL'auteur Johannes Schaub - litb

  4. 3

    En déclarant spécial vide classes pour les couleurs, vous pouvez tout faire à l'aide de modèles. Cela exige que chaque choix de couleur pour être disponible au moment de la compilation. En faisant cela, vous éviter d'avoir à utiliser une classe de base avec des méthodes virtuelles.

    struct Red{};
struct Blue{};
template < typename Color >
class Pen{};
template <>
class Pen< Red >
{
void Draw(){
cout << "Drawing with red pen" << endl;
}
};
template <>
class Pen< Blue >
{
void Draw(){
cout << "Drawing with blue pen" << endl;
}
};
template < typename Color >
std::auto_ptr< Pen< Color > > createPen()
{
return auto_ptr< Pen< Color > >(new Pen< Color >());
}

    OriginalL'auteur Benoît

  5. 1

    Vous pourriez écrire un générique fabrique d'objet de la classe comme une classe de modèle (ou utilisez celui qui est bien décrit dans ce gamedev.net l'article).

    De cette façon, si vous avez plus d'une usine dans votre code, c'est moins de travail pour définir chaque usine.

    OriginalL'auteur RyanCu

  6. 0

    Comme un complément à ma réponse, juste pour discuter de l'Usine modèle contre modèle de useage:

    Le principal (et plus simple) de raison d'utiliser des modèles, c'est que votre code est identique dans tous les cas, sauf pour les types de données. Les exemples ici sont les conteneurs STL.
    Il serait possible d'écrire une fonction de fabrication de createVector("chaîne"), et le type de chaque conteneur manuellement -- mais ce n'est clairement pas optimal.

    Même lorsque le code est différent, non seulement les types de données, il est possible d'utiliser des spécialisations de modèle -- mais dans de nombreux cas, une usine de fonction aurait plus de sens.

    Considérez, par exemple, une abstraction de base de données de la bibliothèque. Il serait possible d'utiliser des spécialisations de modèle, de sorte que la bibliothèque pourrait être utilisé comme "db::driver". Mais ce serait vous obliger à taper le type de base de données partout dans le code (faire de la bibliothèque un peu inutile, en premier lieu,...), ou d'effectuer une affaire à une interface de type db::la classe du pilote.

    Dans cet exemple, il est plus intuitif de dire db::get_driver(odbc) et de revenir à la bonne classe de fonte pour le type d'interface.

    OriginalL'auteur gnud