C# constructor using a dynamic vs Interface as a parameter

Question

In the benefit of creating clean decoupled code in c# I was hoping to get some feedback on using a dynamic parameter to construct objects. Typically I believe you'd create an interface and use the interface as the contract, but then you have to create interfaces for all your classes which I think is kind of icky...

So, my question is what are the pros and cons of doing something like this:

class Class1
{
    public string Description { get; set; }
    public string Name { get; set; }

    public Class1(dynamic obj)
    {
        Name = obj.Name;
        Description = obj.Description;
    }
}

vs

class Class1
{
    public string Description { get; set; }
    public string Name { get; set; }

    public Class1(IClass1 obj)
    {
        Name = obj.Name;
        Description = obj.Description;
    }
}

You might be interested in [ImpromptuInterface](http://code.google.com/p/impromptu-interface/) it allows you to put a implementation at runtime behind an interface. So yes you would have to have a interface declared, but it wouldn't need a statically declared implementation. Aanonymous & dynamic objects could still be used as it would basically have the same behavior as the first option above, but declared like the 2nd option. — jbtule, May 27 '11 at 15:44

score 8 · Accepted Answer · answered May 25 '11 at 17:29

8

Pros of the interface:

The compiler will tell you if you're using the wrong kind of argument
The signature of the constructor tells you what's required from the parameter

Pros of dynamic:

You don't need to declare the interface or implement it
Existing classes with Name and Description properties can be used with no change
Anonymous types can be used within the same assembly if they have Name and Description properties

Personally I typically use C# as a statically typed language unless I'm interacting with something naturally dynamic (e.g. where I'd otherwise use reflection, or calling into COM or the DLR)... but I can see that in some cases this could be useful. Just don't over-do it :)

answered May 25 '11 at 17:29

Jon Skeet

1,421,763
867
9,128
9,194

I'm in the process of refactoring lots of code and don't want to create a bunch of interfaces, because it feels like too much work/complexity. I think my hang ups are more based on how I should instatiate objects (which is another discussion). Thanks for the advice. – Aaron Barker May 25 '11 at 17:51
I think the most important thing is missing: if you use `dynamic` in the constructor, the class [cannot be inherited from](http://stackoverflow.com/questions/8098981/) (without creating a default constructor) – BlueRaja - Danny Pflughoeft Dec 22 '15 at 06:57
@BlueRaja-DannyPflughoeft: You're overstating the restriction. The constructor can't chain dynamically to a base class constructor - that's all. – Jon Skeet Dec 22 '15 at 08:49

score 1 · Answer 2 · answered May 25 '11 at 18:58

In both scenarios for the method to function properly as expected the objects being passed into the method must have your Name and Description properties.

My concern is that the best practice for using a dynamic as you have, you would need to provide additional method documentation to ensure other programmers or even yourself six months from now know the expected data contracts that must be present on the object being passed and even then you really should write error handling into your method to ensure it functions as expected when that contract is broken.

Does all these potential gotchas out weight the hypothetical gain of not writing an interface which in the example given would be literally only a 5 basic lines of code, which would then do everything your forcing yourself to do manually.

Assuming you want to follow best practices which lead to well documented and easy to read code. I would lean towards using an interface for this purpose.

C# constructor using a dynamic vs Interface as a parameter

2 Answers2