C # Design Pattern per lavoratori con diversi parametri di input

Ho riprogettato la soluzione sulla base del commento di @ Dunk:

...you already know all the parameters needed before the IWorker instance is created. Thus, you should have passed those arguments to the constructor and not the DoWork method. IOW, make use of your factory class. Hiding the details of constructing the instance is pretty much the main reason for the factory class's existence.

Quindi ho spostato tutti gli argomenti possibili necessari per creare un IWorker nel metodo IWorerFactory.GetWorker e ogni lavoratore ha già ciò di cui ha bisogno e il coordinatore può semplicemente chiamare worker.DoWork ();

    public interface IWorkerFactory
    {
        IWorker GetWorker(string workerName, int a, List<int> b, string c);
    }

    public class WorkerFactory : IWorkerFactory
    {
        public IWorker GetWorker(string workerName, int a, List<int> b, string c)
        {
            switch (workerName)
            {
                case "WorkerA":
                    return new ConcreteWorkerA(a, b);
                case "WorkerB":
                    return new ConcreteWorkerB(a, b, c);
                default:
                    return null;
            }
        }
    }

    public class Coordinator
    {
        private readonly IWorkerFactory _workerFactory;

        public Coordinator(IWorkerFactory workerFactory)
        {
            _workerFactory = workerFactory;
        }

        // Adding 'c' breaks Open/Closed principal for the Coordinator and WorkerFactory; but this has to happen somewhere...
        public string GetWorkerResult(string workerName, int a, List<int> b, string c)
        {
            var worker = _workerFactory.GetWorker(workerName, a, b, c);

            if (worker != null)
                return worker.DoWork();
            else
                return string.Empty;
        }
    }

    public interface IWorker
    {
        string DoWork();
    }

    public class ConcreteWorkerA : IWorker
    {
        private readonly int _a;
        private readonly List<int> _b;

        public ConcreteWorkerA(int a, List<int> b)
        {
            _a = a;
            _b = b;
        }

        public string DoWork()
        {
            // does the required work based on 'a' and 'b'
            return "some A worker result";
        }
    }

    public class ConcreteWorkerB : IWorker
    {
        private readonly int _a;
        private readonly List<int> _b;
        private readonly string _c;

        public ConcreteWorkerB(int a, List<int> b, string c)
        {
            _a = a;
            _b = b;
            _c = c;
        }

        public string DoWork()
        {
            // does some different work based on the value of 'a', 'b' and 'c'
            return "some B worker result";
        }
    }

Sarà necessario generalizzare gli argomenti in modo che si adattino a un singolo parametro con un'interfaccia di base e un numero variabile di campi o proprietà. Un po 'come questo:

public interface IArgs
{
    //Can be empty
}

public interface IWorker
{
    string DoWork(IArgs args);
}

public class ConcreteArgsA : IArgs
{
    public int a;
    public List<int> b;
}

public class ConcreteArgsB : IArgs
{
    public int a;
    public List<int> b;
    public string c;
}

public class ConcreteWorkerA : IWorker
{
    public string DoWork(IArgs args)
    {
        var ConcreteArgs = args as ConcreteArgsA;
        if (args == null) throw new ArgumentException();
        return "some A worker result";
    }
}

public class ConcreteWorkerB : IWorker
{
    public string DoWork(IArgs args)
    {
        var ConcreteArgs = args as ConcreteArgsB;
        if (args == null) throw new ArgumentException();
        return "some B worker result";
    }
} 

Nota i controlli null ... perché il tuo sistema è flessibile e in ritardo, non è sicuro anche per il tipo, quindi dovrai verificare il cast per assicurarti che gli argomenti passati siano validi.

Se davvero non vuoi creare oggetti concreti per ogni possibile combinazione di argomenti, puoi usare un tupla invece (non sarebbe la mia prima scelta.)

public string GetWorkerResult(string workerName, object args)
{
    var workerFactor = new WorkerFactory();
    var worker = workerFactor.GetWorker(workerName);

    if(worker!=null)
        return worker.DoWork(args);
    else
        return string.Empty;
}

//Sample call
var args = new Tuple<int, List<int>, string>(1234, 
                                             new List<int>(){1,2}, 
                                             "A string");    
GetWorkerResult("MyWorkerName", args);

Suggerirei una delle varie cose.

Se vuoi mantenere l'incapsulamento, in modo che i calliti non debbano sapere nulla sul funzionamento interno degli operai o della fabbrica dei lavoratori, allora avrai bisogno di cambiare l'interfaccia per avere il parametro extra. Il parametro può avere un valore predefinito, in modo che alcuni calliti possano ancora utilizzare solo 2 parametri. Ciò richiederà che tutte le librerie di consumo vengano ricompilate.

L'altra opzione la sconsiglio, poiché rompe l'incapsulamento ed è solo un OOP generalmente sbagliato. Ciò richiede anche che tu possa almeno modificare tutti i callites per ConcreteWorkerB . Puoi creare una classe che implementa l'interfaccia IWorker , ma ha anche un metodo DoWork con un parametro extra. Quindi, nei callites, prova a lanciare IWorker con var workerB = myIWorker as ConcreteWorkerB; e quindi utilizza il parametro three DoWork sul tipo concreto. Di nuovo, questa è una cattiva idea, ma è qualcosa che potresti fare.

@Jtech, hai considerato l'uso dell'argomento params ? Ciò consente di passare una quantità variabile di parametri.

link