Dependency problem in C#, through polymorphism, and appropriate design pattern

I'm currently working on a project which involves EntityFramework with a (very) rich model (lots of inheritance). I'm currently facing a problem, quite interesting in my opinion.

My model is described in the Domain namespace. It involves 2 classes that inherit from 1 abstract class.

What I want to do is to be able to perform some specific actions on instances of these classes without knowing their concrete type. I could of course use abstract or virtual methods directly in the model.

But I have many reasons for not doing that:

• I want to keep my model classes as straight POCOs

• In real life, those modifying methods will have dependencies on other objects (that could be database or network retrieving of information), and I want to keep my model without any dependency

After reading on that problem it appeared to me that a solution to this problem is to use the Visitor pattern. But this implies to modify my model, so I thought about finding another solution, and I came to this one.

I've 2 problems with that solution:

• The use of the dynamic keyword in the static resolution mechanism

• The abstract getter in the public abstract class PersonModifier

Is this a known pattern? If not, is it clean? If not, is there an appropriate pattern to perform such an operation?

```
namespace Domain
{
public abstract class Person
{
public int Age { get; set; }
public string Name { get; set; }
}

public class Child : Person
{
public decimal PocketMoney { get; set; }
}

public class Adult : Person
{
public string FavoriteBook { get; set; }
}
}

namespace Modifiers
{
public static class Resolver
{
private static PersonModifier ConcreteResolve(Domain.Child person)
{
return new ChildModifier(person);
}

private static PersonModifier ConcreteResolve(Domain.Adult person)
{
return new AdultModifier(person);
}

private sta

I want to keep my model without any depdency

When one class uses another, that's dependency. OO programming is all about dependencies - we do not (should not) make single monolithic, do-all classes. However Decoupling direct dependencies is what all the 'oopla is about.


System.Console.WriteLine("Name:" + child.Name + ", Age:" + child.Age + ", PocketMoney:" + child.PocketMoney);

Should be more like System.Console.WriteLine(child), where of course ToString() is overridden. Single Responsibility Principle.

var adult = new Domain.Adult
        {
            Age = 42,
            Name = "Lola",
            FavoriteBook = "Dorian Gray"
        };

Instead use Constructor parameters, providing the opportunity for validating arguments.


POCO is loco

What's the point of any class when we can shovel scheiss anywhere at anytime using any value? If we cannot have some modicum of "state management" why have any particular class at all?

As your project grows sooner or later it will dawn on you that all the Person and derivative class functionality is everywhere in the client code and nowhere in the class itself! Woe betide the maintenance programmer.

Command Pattern Trying To get out?

That's what it feels like to me. C.P. purpose is to decouple the requestor and performer of a request.

MVC is about decoupling dependencies

At this higher level perspective we can swap out model or view or controller components. Perhaps instead of (what I see as) odd class metamorphosis, design a coherent (business) model and have customized controllers as needed.

Closures and delegates

I've used this idea, where setting the delegate via constructor overloads. Each delegate iterated a different data structure but otherwise performed the same function.

public class Child : Person 
{
    protected Func Allowance;
    public double PocketMoney {get; protected set;}

    public Child (int goodBoyBonus) {
        goodBoyBonus = goodBoyBonus  PMdelegate) {
        if (PMdelegate == null) throw new ArguementNullException();
        Allowance = PMdelegate;
    }

    public PerformSpecificActions() { Allowance(); }
}

And maybe there are several pre-made "delegations" and via a constructor or a factory method the desired delegate is specified. This technique can be applied as the command pattern without command objects per se.

StackExchange Code Review Q#121121, answer score: 5