Discussion :

[Seabirds]

Salut à toutes et à tous !

Une question de débutant... mais que je n'arrive pas à trouver sur mes moteurs de recherche préférés...

Une classe Factory est templatée sur le type T d'objets à fabriquer : Factory<T>, et elle construit T petit à petit en appelant certains services.
En l'état, elle marche avec une première classe A, et Factory<A>::build() marche très bien.
Au moment de coder une deuxième classe B pour pouvoir instancier une Factory<B>, je me vois obligé de re-parcourir l'implémentation de la Factory pour lister les services de D qu'elle nécessite pour la construction. C'est faisable parce que ma classe Factory n'est pas non plus démente, mais c'est assez pénible à faire pour que je me doute que les vrais développeurs s'y prendraient autrement. Ma question était de savoir comment

Bien cordialement

[ternel]

Je ne comprends pas ton problème précis, mais il me semble que tu devrai te renseigner sur "interface segregation principles", le I de SOLID

Les hiérarchies OO ne sont pas toujours la solution, mais pour en dire plus, il faut un contexte plus précis.

[Seabirds]

OK merci de ta réponse
J'ai édité le message précédent. Est-ce plus clair ?
J'avais déjà lu sur l'ISP. D'ailleurs je crois bien que quelque part mon ennui est que j'ai poussé l'ISP à l'extrême en ne regroupant aucun service

[bacelar]

Une "Factory" n'est pas forcement template, c'est même assez rarement le cas.
Si A et B sont constructibles via Factory<X>, c'est qu'ils partagent assez de point commun pour qu'un template (avec quelques spécialisations si nécessaire) puisse construire indifféremment l'un ou l'autre.

Vous prenez le problème dans le mauvais sens.

Vous voulez que A et B soient constructibles via un DP Factory, vous devez commencer par spécifier l'API que A et B (et les autres classes constructibles) doivent implémenter pour être constructible.
Une fois cette API spécifiée, l'implémentation de Factory<X> l'utilise.

Et les concepteurs des classes A, B et autres, n'ont cas implémenter cette API de construction.

[koala01]

Salut,

Une "Factory" n'est pas forcement template, c'est même assez rarement le cas.
Si A et B sont constructibles via Factory<X>, c'est qu'ils partagent assez de point commun pour qu'un template (avec quelques spécialisations si nécessaire) puisse construire indifféremment l'un ou l'autre.

Vous prenez le problème dans le mauvais sens.

Vous voulez que A et B soient constructibles via un DP Factory, vous devez commencer par spécifier l'API que A et B (et les autres classes constructibles) doivent implémenter pour être constructible.
Une fois cette API spécifiée, l'implémentation de Factory<X> l'utilise.

Et les concepteurs des classes A, B et autres, n'ont cas implémenter cette API de construction.

Je ne peux que plussoyer!!!

En fait, si tu veux faire une fabrique template, il faut non pas un paramètre template mais deux, sous une forme qui serait sans doute proche de

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
template<typename Type, typename Policy>
class Factory{
    std::unique_ptr<A> create() const{
        return Policy().create();
    }
/* ... */
};

où type correspond au "type de base renvoyé par la fabrique" et où polycy correspond à "tout ce qui doit être fait pour construire l'élément demandé".

Ainsi, le créateur de la classe A devrait fournir non seulement la classe A, mais aussi la politique qui permet la création de cette classse, sous une forme qui pourrait être proche de

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
class A{
    /* tout ce que le createur de la classe peut souhaiter */
};
struct
TheMainingfullCreatorForA{
    std::unique_ptr<A> create() const{
        /* tout ce qui doit être fait */
        return std::make_unique<A>(/* paramètres éventuels spécifiques à A */ );
    }
};

Maintenant, on pourrait sans doute également envisager de fournir l'interface spécifique pour Policy, sous une forme qui serait sans doute proche de

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
template <typename T>
ObjectCreator{
    template <typename DERIVED>
    std::unique_ptr<T> create() const;
};

De cette manière, il deviendrait possible de fournir une spécialisation (complète) de la ObjectCreator::create renvoyant un std::unique_ptr sur n'importe que type de base (spécialisation de T), mais dont le type réel correspondrait à n'importe quelle classe dérivée (spécialisation de DERIVED), et notre classe Factory pourrait alors prendre la forme de

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
template <typename T, typename Policy = OBjectCreator<T>>
class Factory{
public:
    template <typename DERIVED
    std::unique_ptr<T> create() const{
        return Policy()::create<DERIVED>();
    }  
};

Mais bon, si on en arrive à ce point, on se demande quel est l'intérêt de la fabrique par rapport à celui de la classe que j'ai appelée ObjectCreator... Même si l'on pourrait estimer que le deuxième s'occupera surtout de rassembler et de regrouper des données utiles à la création (DP builder inside )

[Seabirds]

Merci pour vos réponses et l'échantillon de code, ça m'a servi pour tout ré-écrire !
En fait, même si je semble être parvenu à mes fins, peut-être que je n'ai pas vraiment compris ce que je voulais faire.
Je voulais dire à un objet "je te donne telle stratégie de simulation et telles données, fabrique moi ce dont j'ai besoin".
Voilà dessous le code que j'ai fait :

Ce que j'ai appellé "Factory" (peut être à tort) :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
class Factory
{
public:
	template<typename simulation_trait>
	auto create(typename simulation_trait::data_type const& data) const {
		return Object<simulation_trait>(data);
	}
};

Ce que j'ai appelé simulation_traits c'est des petites classes de traits dans un namespace :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
namespace simulation_traits
{
	struct strategy1 {	using data_type = double; };
	struct strategy2 { using data_type = unsigned int; };
}

L'objet à fabriquer, qui contient en fait deux sous objets dont les types sont dépendants :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
template<typename simulation_trait>
class Object
{
private:
	using A_type = A<simulation_trait>;
	using B_type = typename A_type::B_type;
	using data_type = typename simulation_trait::data_type;
	A_type m_A;
	B_type m_B;
public:
        Object(data_type const& data) : m_A(data), m_B(data) {}
};

Et enfin des spécialisations pour les différentes implémentations qui varient selon les stratégies de simulation:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
template<typename Trait>
class A{};
 
template<>
class A<simulation_traits::strategy1> { // implémentation 1};
 
template<>
class A<simulation_traits::strategy2> { // implémentation 2};
 
// et pareil pour B

Qu'en pensent les experts ? A quel point c'est une usine à gaz ? Pourquoi est-ce que manifestement le nom de Factory est mal choisi ?
Et enfin, la question initialement posée (même si les choses ont un peu évoluées entre temps) : est-ce que je me plante à ne pas faire hériter les différents A et B d'une même interface ?

[jo_link_noir]

Pour moi, une factory est plus intelligente que ça et retourne un type de base d'un ensemble de classe dérivé. Par exemple, un type Image qui est en fait un Png, Gif, etc. Là, c'est tellement "basique" que my_factory.create = Object.

Je ne suis pas non plus certain de la pertinence de simulation_traits. Si chaque A est spécialisé sur un trait, les traits ne servent pas, ou alors A est lui-même un trait.

Est-ce que je me plante à ne pas faire hériter les différents A et B d'une même interface ?

Interface, c'est plutôt large, cela peut être une interface sur les identifiants et la catégorie des types (avoir tel membre, respecte tel concept ; comme dans la programmation générique) ou une interface sur les types (polymorphisme classique).

Si les spécialisations de A on une interface publique avec les mêmes types d'entrées et de sorties, tu peux envisager une interface à base de fonctions virtuelles.
Si au contraire, les types d'entrées et de sorties diffèrent et qu'on ne peut décemment pas les mettre en commun, des templates sont à envisager.

La frontière est beaucoup plus ténue et rien n'empêche les mélanges, il faudrait plus d'information sur les différents acteurs pour se décider.

[dragonjoker59]

Pour la factory non template, je suis perplexe, j'ai ça chez moi:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
 
template< class Obj
    , class Key
    , class PtrType = std::shared_ptr< Obj >
    , class Creator = std::function< PtrType() >
    , class Predicate = std::less< Key > >
class Factory
{
protected:
    using ObjPtr = PtrType;
    using CreatorMap = std::map< Key, Creator, Predicate >;
 
public:
    Factory() = default;
    ~Factory() = default;
 
    void Register( Key const & p_key, Creator p_creator )
    {
        m_registered[p_key] = p_creator;
    }
 
    void Unregister( Key const & p_key )
    {
        auto l_it = m_registered.find( p_key );
 
        if ( l_it != m_registered.end() )
        {
            m_registered.erase( p_key );
        }
    }
 
    template< typename ... Parameters >
    ObjPtr Create( Key const & p_key, Parameters && ... p_params )const
    {
        ObjPtr l_return;
        auto l_it = m_registered.find( p_key );
 
        if ( l_it != m_registered.end() )
        {
            l_return = l_it->second( std::forward< Parameters >( p_params )... );
        }
        else
        {
            throw std::runtime_error{ "Unknown object type" };
        }
 
        return l_return;
    }
 
protected:
    CreatorMap m_registered;
};

Et je n'ai pas encore eu besoin de plus.

[Seabirds]

Merci pour vos réponses !

Si les spécialisations de A on une interface publique avec les mêmes types d'entrées et de sorties, tu peux envisager une interface à base de fonctions virtuelles.
Si au contraire, les types d'entrées et de sorties diffèrent et qu'on ne peut décemment pas les mettre en commun, des templates sont à envisager.

Et quand on sait pas trop et qu'on navigue à vue, j'imagine qu'on opte aussi pour les templates ?

Pour la factory non template, je suis perplexe, j'ai ça chez moi:

Oh, merci pour le parameter pack, j'ai du mal avec la syntaxe, ça fait du bien d'avoir une piqure de rappel de temps à autres
Je n'ai pas trop bien compris le type Creator : dans le std::function, y'a quoi ? Une fonction libre ou le constructeur ?

[dragonjoker59]

Généralement j'utilise une fonction membre statique, et je mets le constructeur en protégé

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
class A
{
protected:
  A()
  {
  }
 
public:
  virtual void hello()const = 0;
};
 
class B
  : public A
{
private:
  B()
    : A{}
  {
  }
 
public:
  void hello()const override
  {
    std::cout << "B" << std::endl;
  }
 
  static std::shared_ptr< A > Create()
  {
    return std::make_shared< B >();
  }
};
 
class C
  : public A
{
private:
  C()
    : A{}
  {
  }
 
public:
  void hello()const override
  {
    std::cout << "C" << std::endl;
  }
 
  static std::shared_ptr< A > Create()
  {
    return std::make_shared< C >();
  }
};
 
int main()
{
  Factory<int, A> factory;
  factory.Register( 1, &B::Create );
  factory.Register( 2, &C::Create );
  auto value = factory.Create( 1 );
  value->hello();
}

[Seabirds]

Ok je comprends mieux !
J'ai mis la discussion comme résolue, avec tous les éléments qu'il y a là j'ai de quoi faire pour le prochain polissage de code
Merci à tous pour vos contributions !