Modèle d'objet pour les personnes/travailleurs qui peuvent être de plusieurs types ("jobs")

Question

Supposons que je modélise une main-d'œuvre de bourreaux de travail. Nous avons Bob, qui est à la fois plombier et charpentier de métier. Il y a Jane, qui est enseignante. Et enfin Jack, le détective, entrepreneur de bowling-alley, et scientifique fou.

Chaque position ou type de travail peut avoir des propriétés ou des méthodes spécifiques à ce travail uniquement. Par exemple, un plombier aura des méthodes comme fixLeakingSink() et des propriétés comme exposedButtCrack qu'un enseignant n'aura pas. Mais, il y aura quelques propriétés et méthodes partagées.

Si ma super-classe est une travailleuse et que j'évite l'héritage multiple, quelle est la meilleure façon de modéliser un scénario comme celui-ci? J'ai d'abord envisagé d'utiliser le motif de conception de décorateur, mais je ne suis pas sûr que ce soit l'application correcte pour cela. (Si connaître la langue dans laquelle cela sera implémenté est utile, ou si vous voulez inclure des extraits de code dans votre explication, c'est PHP5.)

Answer 1

Je voudrais probablement utiliser la composition et avoir un travailleur qui a une collection de travaux. Chaque travail peut avoir une interface commune, mais peut également inclure ses propres méthodes. Decorator ne s'applique pas vraiment ici car il suppose une interface commune dans laquelle vous construisez l'implémentation de cette interface unique. L'utilisation de la composition vous permettrait d'avoir un travailleur commun avec la possibilité d'avoir un nombre quelconque de Jobs possibles de différents types.

C mise en œuvre de #:

public interface IWorker 
{ 
    void AddJob(Job job); 
    void RemoveJob(Job job); 
    void SetCurrentJob(Job job); 
    Job GetCurrentJob(); 
} 

public interface IJob 
{ 
    void Work(); 
} 

public class Worker : IWorker 
{ 
    private List<Job> Jobs { get; set; } 

    private int CurrentJob { get; set; } 

    public Worker() 
    { 
     this.Jobs = new List<Job>(); 
     this.CurrentJob = -1; 
    } 

    public void AddJob(Job job) 
    { 
     this.Jobs.Add(job); 
    } 
    public void RemoveJob(Job job) { ... } 
    public void SetCurrentJob(Job job) { ... } 
    public Job GetCurrentJob() 
    { 
     return this.CurrentJob > 0 ? this.Jobs[this.CurrentJob] : null; 
    } 
} 

public class Bartender : IJob 
{ 
    public Work() 
    { 
     this.OpenBar(); 
     this.TendBar(); 
     this.Close(); 
     this.CleanUp(); 
    } 

    public void OpenBar() { ... } 
    public void TendBar() { ... } 
    public void Close() { ... } 
    public void CleanUp() { ... } 
} 

Answer 2

Cela semble assez simple.

Chaque type d'emploi étend travailleur

travailleur contient (références) une collection d'instances d'emploi.

Le travail n'a aucune relation d'héritage avec quoi que ce soit (sauf si vous souhaitez ajouter plus d'informations au problème).

Answer 3

Je lirais quelques articles de Martin Fowler: Dealing with Roles et Accountability, puis décider.