2012-09-27 4 views
0

Je développe un code en utilisant le modèle Boss-Worker. J'ai un doute. La liste à laquelle le Boss va s'ajouter est un membre de la classe Boss. Pour que le travailleur puisse y accéder, je fais hériter la classe Worker de Boss.Conception du modèle Boss-Worker

1) Est-ce la bonne façon de partager la liste entre le boss & Worker?
2) Je suis confronté à un héritage ambigu dans mon code. Comment puis-je le résoudre?

ThreadClass

#include <pthread.h> 
class ThreadClass 
{ 
public: 
    virtual int start(); 
    virtual void join(); 
    virtual void execute() = 0; //Each derived class will implement this 
    virtual ~ThreadClass() {} 
    ThreadClass() {} 
private: 
    ThreadClass* Tptr; 
}; 

Patron

#include "ThreadClass.h" 
#include <list> 

class Boss : public virtual ThreadClass 
{ 
public: 
    virtual void execute(); 
    Boss() {} 
    ~Boss() {} 

protected: 
    std::list<int> Mylist; //To be shared with the worker 
}; 

Travailleur

#include "ThreadClass.h" 
#include "Boss.h" 
class Worker : public Boss, public ThreadClass //Getting error:Ambiguous ThreadClass 
{ 
public: 
    virtual void execute(); 
    Worker() {} 
    ~Worker() {}  
}; 

travailleur hérite de Boss & ThreadClass parce que:

1) Le travailleur a besoin d'accéder à la liste de Boss
2) Le travailleur a besoin de filetage fonctions de ThreadClass

Répondre

2

La liste que le patron ajoutera à, est un membre de la classe patron. Pour que le travailleur puisse y accéder, je fais hériter la classe Worker de Boss.

Ceci est catégoriquement pas une bonne raison pour une classe à hériter d'une autre. Habituellement, Worker devrait hériter de Boss si et seulement si vous pouvez substituer un Worker dans n'importe quel endroit que vous pourriez utiliser un Boss. Conceptuellement, ce n'est pas le cas ici.

Si vous souhaitez donner accès à la liste de Boss de int puis, si le Worker connaît les Boss fournissent et accesseur en Boss ou (éventuellement) faire Worker un friend de Boss.

Si vous ne voulez pas Worker savoir sur Boss mais ont Boss savent sur Worker s alors faire passer Boss la liste à Worker soit au moment de la construction ou à un moment approprié plus tard.

Fournir l'accès à quelque chose n'est pas une raison pour faire qu'une classe dérive d'une autre.

+0

J'ai compris votre point. Le travailleur "n'est pas un" patron à hériter de lui. – cppcoder

1

Je découpler toutes les classes et la composition faveur. Les deux Worker et Boss peuvent partager une liste créée de manière externe en maintenant une référence à celle-ci. En ce qui concerne la fonctionnalité de thread, l'approche C++ 11 et boost.thread consiste à avoir des types de thread qui prennent des entités "appelables". Je pense que cette approche découplée est plus propre que le double héritage que vous proposez. D'ailleurs, vous devrez peut-être déployer votre propre classe de liste simultanée pour cela. std::list ne sera pas sûr contre les écritures d'au moins l'un des threads threads, si un thread différent lit simultanément.

class ConcurrentList { .... }; 
class Boss 
{ 
    ConcurrentList& list_; 
public: 
    Boss(ConcurrentList& l) : list_(l) 
    // other methods 
}; 
class Worker 
{ 
    ConcurrentList& list_; 

public: 
    Worker(ConcurrentList& l) : list_(l) 
    // other methods 
}; 
class Thread 
{ 
    // implement a call-cack mechanism 
}; 
+0

Si l'écriture est effectuée par seulement 1 thread et plusieurs threads lus dans la liste, 'std :: list' suffirait-il? – cppcoder

+0

@cppcoder Je ne pense pas, parce que les lectures ne sont pas atomiques. Vous pourriez lire un emplacement en même temps qu'un autre thread le modifie. – juanchopanza