Constructor from interface with minimal repetition

Question

Preface

In an application that is separated by layers or distributed by services it is common to have classes that are very closely related data-wise, but which we wish to have loosely coupled. My usual solution (in c#) is to have them implement a common interface. (There are other patterns, but this is what I default to)

I might (for example) have a backend data entity Foo

public class Foo:IFoo
{
    public int DatabaseKey {get; set;}
    public string NaturalKey {get; set;}
    public string SomeProperty {get; set;}
}

a data contract class FooDto

[DataContract]
public class FooDto:IFoo
{
    [DataMember]
    public string NaturalKey {get; set;}
    [DataMember]
    public string SomeProperty {get; set;}
}

and an MVC model class FooModel

public class FooModel:IFoo
{
    public string NaturalKey {get; set;}
    public string SomeProperty {get; set;}
    public string CssClass {get; set;}
}

all implementing a common interface IFoo

public interface IFoo
{
    string NaturalKey {get;}
    string SomeProperty {get;}
}

My Question

When mapping those incarnations of Foo onto each other I might use an object mapper (ie automapper), but for smaller projects or when policy prevents third party software I add a constructor which takes the interface as a parameter, ie

public Foo(IFoo template):base()
{
    NaturalKey = template.NaturalKey;
    SomeProperty = template.SomeProperty;
    //additional code
}

etc

How can I avoid unnecessarily repeating the assignments from template to properties across the different classes? Assume that the general pattern is given as is the decision not to use an object mapper. Note that the assignments might differ in some cases (inferring explicit defaults for null values etc)

Answer 1

None of the objects has to contain properties where its data reside. Objects are not data containers, they are smart units of behavior. You could embrace what Alan Kay, a man behind Smalltalk, thought about objects. He wanted them to get rid of data. So if you need to persist them, ok, it might look like that:

class User
{
    private $id;
    private $dataSource;

    public function __construct(UUID $id, DataSource $dataSource)
    {
        $this->id = $id;
        $this->dataSource = $dataSource;
    }

    public function register(FullName $fullName, Passport $passport, Email $email)
    {
        $this->dataSource
            ->save(
                $this->id,
                $fullName,
                $passport,
                $email
            )
        ;
    }
}

This approaches solves the root problem: treating object like data bags. It reflects a procedural mindset that encompasses a good part of software developers. You could try different hacks and workarounds, like using reflection or passing a DTO to model entity, but it doesn't solve the root cause of your problem. Basically, any object should possess all resources it needs to implement its responsibilities. Here are some more examples and guidelines.

Anticipating your question about how to avoid copy-pasting data to View or ModelView classes, the answer is the same. In OOP, any object is responsible for displaying itself. So your object could return an xml object that could be represented in browser with XSLT:

class User
{
    private $id;
    private $dataSource;

    public function __construct(UUID $id, DataSource $dataSource)
    {
        $this->id = $id;
        $this->dataSource = $dataSource;
    }

    public function display()
    {
        $data = $this->dataSource->byId($this->id);

        return
            (new Xml())
                ->add('name', $data['name'])
                ->add('passport_number', $data['passport_number'])
                ->add('email', $data['email'])
            ;
    }
}

Here is more about this technique.

Once again, unless you stop treating your program as a flow of passive data that is operated upon some procedures, you'll never get rid of constant getting-and-setting since it is the nature of procedural programming.

Answer 2

These kinds of classes are essentially data structures used to move data across the boundaries of the application, and so are not objects in the OOP sense. The classes generally have no logic, or have very little logic, and mostly act as property bags.

And, unless I'm mistaken, one of the key things they need to support in the scenario you describe is copying property values from one type to another; one way to support that is to have your IFoo interface declare read/write properties.

public interface IFoo
{
    string NaturalKey {get; set;}
    string SomeProperty {get; set;}
}

Then you could simply define an extension method that takes two IFoo instances, and copies the properties:

public static void CopyFrom(this IFoo destination, IFoo source) 
{
    destination.NaturalKey = source.NaturalKey;
    destination.SomeProperty = source.SomeProperty;
}

You can then use it like this:

foo1.CopyFrom(foo2);

You may feel that this is not entirely OO, but applications are not object oriented at the boundaries, and that's where these classes appear.

P.S. I understand that there could be something that prevents you to use this approach, and that there could be a good reason behind your decision to declare the interface with with get-only properties - but maybe you can adapt the idea somehow to suit your case.

Answer 3

You could write a base class that performs a default copy of all properties, assigning default values (which need to be implemented by subclasses) if property values are not valid.

Example:

public interface IFoo
{
    string NaturalKey {get;}
    string SomeProperty {get;}
}

public abstract class BaseFoo : IFoo
{
    public string NaturalKey {get;}
    public string SomeProperty {get;}

    public abstract string DefaultNaturalKey {get;}
    public abstract string DefaultSomeProperty {get;}

    protected void CopyFrom(IFoo sourceFoo) 
    {
        if (string.IsNullOrEmpty(sourceFoo.NaturalKey)) 
        {
            NaturalKey = DefaultNaturalKey;
        } 
        else
        {
            NaturalKey = sourceFoo.NaturalKey;
        }

        if (string.IsNullOrEmpty(sourceFoo.SomeProperty)) 
        {
            SomeProperty = DefaultSomeProperty;
        } 
        else
        {
            SomeProperty = sourceFoo.SomeProperty;
        }

        //...and so on...
    }
}

public class Foo : BaseFoo {

    public override string DefaultNaturalKey { get { return "MyKey"; } }
    public override string DefaultSomeProperty { get { return "MyProperty"; } }

    public Foo(IFoo template) : base()
    {
        CopyFrom(template);

        //additional assignments, if necessary
    }
}