4

I've got a list of different jobs to process in my application. I'm toying with a design which uses different types to represent different types of job - this is natural because they have different properties and so on. For processing I was thinking about using the dynamic keyword in C# as per the code below. 

abstract class Animal {}    
class Cat : Animal {} 
class Dog : Animal {}

class AnimalProcessor
{
    public void Process(Cat cat)
    {
        System.Diagnostics.Debug.WriteLine("Do Cat thing");
    }

    public void Process(Dog dog)
    {
        System.Diagnostics.Debug.WriteLine("Do Dog thing");
    }

    public void Process(Animal animal)
    {
        throw new NotSupportedException(String.Format("'{0}' is type '{1}' which isn't supported.",
            animal,
            animal.GetType()));
    }
}

internal class Program
{
    private static void Main(string[] args)
    {
        List<Animal> animals = new List<Animal>
        {
            new Cat(),
            new Cat(),
            new Dog(),
            new Cat()
        };

        AnimalProcessor animalProcessor = new AnimalProcessor();
        foreach (dynamic animal in animals)
        {
            animalProcessor.Process(animal);
        }

        //Do stuff all Animals need.
    }
}

The code works as expected, but, I have a nagging feeling that I'm missing something blindingly obvious and that there's a much better (or better known) pattern to do this.

Is there any better or equally good but more accepted pattern to use to process my Animals? Or, is this fine? And, please explain why any alternatives are better.

Daniel James Bryars
  • 4,429
  • 3
  • 39
  • 57
  • If you have control over source code of all involved class, `dynamic` would be an overkill here. Just make `Animal.Process` an `abstract` method and override it in derived class. – noseratio Feb 18 '14 at 04:55

3 Answers3

8

You are not missing anything: dispatching on runtime type of the object is something that dynamic can do quite well.

You do have alternatives, such as implementing the visitor pattern, but it is much costlier in terms of implementation, and it is also not nearly as readable as your approach that uses dynamic:

interface IAnimalProcessor { // The visitor interface
    void Process(Cat cat);
    void Process(Dog dog);
    void Process(Animal animal);
}
class AnimalProcessor : IAnimalProcessor {
    ...
}
interface IProcessable {
    void Accept(IAnimalProcessor proc);
}
class Cat : IProcessable {
    public void Accept(IAnimalProcessor proc) {
        proc.Process(this); // Calls the Cat overload
    }
}
class Dog : IProcessable {
    public void Accept(IAnimalProcessor proc) {
        proc.Process(this); // Calls the Dog overload
    }
}
...
AnimalProcessor animalProcessor = new AnimalProcessor();
foreach (IProcessable animal in animals) {
    animal.Accept(animalProcessor); // The animal will call back the right method of the proc
}
Sergey Kalinichenko
  • 714,442
  • 84
  • 1,110
  • 1,523
3

This is definitely bad design.
You simply can't introduce interface for AnimalProcessor, as adding new Animal subclass will cause interface to change.
More over, the client of your AnimalProcessor should know about the special construct(foreach with dynamic) for class usage. If you still want to use "dynamics" in this case, consider something like:

class AnimalProcessor
{
    public void Process(Animal animal)
    {
        dynamic concreteAnimal = animal;

        DoProcess(concreteAnimal);
    }

    private void DoProcess(Animal animal)
    {
        throw new NotImplementedException();
    }

    private void DoProcess(Cat cat)
    {
        System.Diagnostics.Debug.WriteLine("Do Cat thing");
    }

    private void DoProcess(Dog dog)
    {
        System.Diagnostics.Debug.WriteLine("Do Dog thing");
    }
}

At least, you will be able to extract interface in future and have different implementations of AnimalProcessor. And still you will have one serious problem: this is absolutely not obvious, that after adding subclass you need to add method to some standalone class, or your system will throw.

FireAlkazar
  • 1,795
  • 1
  • 14
  • 27
  • +1. Yes, I like your point about the interface. Hiding the implementation of the "dispatch" behind an interface with one method (ie void Process(Animal animal)) solves this. But then, the actual act of processing each different animal type can be implemented using the visitor pattern, or using dynamic. – Daniel James Bryars Feb 18 '14 at 11:55
  • As for me, I don't like the visitor pattern for this case, I even more like Chain of Responsibility. But still the simplest map would be the best choice imo. Check the related links, if u are interested: http://stackoverflow.com/questions/14613971/use-visitor-pattern-to-handle-else-if/14627729#14627729, http://stackoverflow.com/questions/1477471/design-pattern-for-handling-multiple-message-types – FireAlkazar Feb 18 '14 at 12:07
  • Thank you. The Chain of Responsibility is interesting. I particularly like your second link (the example with the message processing). – Daniel James Bryars Feb 18 '14 at 19:55
  • 1
    [There is an implementation of Visitor pattern using dynamic](http://code.logos.com/blog/2010/03/the_visitor_pattern_and_dynamic_in_c_4.html) keyword and I wrote the same code as @FireAlkazar answering your question. It is better to use all good C# features instead of sticking to the old-school GoF implementation. – Ilya Palkin Feb 19 '14 at 11:10
1

What you might want to do is not use the dynamic type and use your base type. This would perform better.

In your case since you are calling the base process method. This is basic Polymorphism

foreach (Animal animal in animals)
{
    animal.Process();
}
tkweli112
  • 11
  • 4