ansaurus

Question

Answer 1

A:

As a general principle, the classes at the root of the tree should all be abstract, because they are all incomplete.

When only the types specific to the individual customer application are made concrete, your problem of inadvertently creating other classes goes away.

Steve Gilham 2009-10-12 21:30:31

Answer 2

+1 A:

Sounds like a good candidate for using Dependency Injection - To get you started take a look at this example on the Spring.NET site. Apologies for the brief reply but I can elaborate tonight when I have some more time to sit down and code a quick example more relevant to your post.

EDIT: Okay first lets introduce two child objects, TinasModeling.Model and BobTheBuilder.Builder

public class Model : IPerson
{
    private bool canAct;
    public bool CanAct
    {
        get { return canAct; }
        set { canAct = value; }
    }

    private double weight;
    public double Weight
    {
        get { return weight; }
        set { weight = value; }
    }

    public Model()
    {
    }

    public bool PayPerson(double Amount)
    {
        if (canAct)
            RequestFilmBoxOfficeRevenue();
        Pay();
    }

    public bool NewJobRequest()
    {
        SendPhotoPortfolioToClient();
        SendJobLocationToModel();
        if (canAct)
            NotifyFilmCrew();
        if (weight < 40.00)
            ContactNutritionist();
    }
}

public class Builder : IPerson
{
    private bool canOperateDigger;
    public bool CanOperateDigger
    {
        get { return canOperateDigger; }
        set { canOperateDigger = value; }
    }

    private double certifiedBuilder;
    public double CertifiedBuilder
    {
        get { return certifiedBuilder; }
        set { certifiedBuilder = value; }
    }

    public Builder()
    {
    }

    public bool PayPerson(double Amount)
    {
        ReuqestTimeSheet();
        Pay();
    }

    public bool NewJobRequest()
    {
        SendBluePrintsToBuilder();
        if (!certifiedBuilder)
            RequestLegalAdvice();
        if (canOperateDigger)
            RequestDrivingPermit();
    }

Both classes are implemented in separate projects - they don't have to be but they are for reasons that I will explain later. As you can see they both do things differently but have one thing in common and that is that they implement the IPerson interface.

public interface IPerson
{
    bool PayPerson(double Amount);
    bool NewJobRequest();
}

This interface is implemented, again, in a separate assembly than both the above mentioned objects and hence our child objects references this assembly, lets call it BOL (Business Object Layer). In the BOL we implement another class called PersonController

public class PersonController
{
    private IPerson thePerson;
    public IPerson ThePerson
    {
        get { return this.thePerson; }
        set { this.thePerson = value; }
    }

    public PersonController()
    {
    }

    public bool PayPerson(double Amount)
    {
        return this.thePerson.PayPerson(Amount);
    }

    public bool NewJob()
    {
        return this.thePerson.NewJobRequest();
    }
}

The most important thing to notice about PersonController is the ThePerson property. This is going to be our dependency injection point. It is worth pointing out at this stage that the BOL layer is completely decoupled from any child objects. This is an important feature that is going to give a lot of flexibility come deployment and maintenance time.

Now we use and configure what we have built so far. Our application only references the BOL layer (decoupling also our main app from any child objects). In our main application we use the Spring.NET Spring.Core assembly and in a app.config file we add the following (for readability I have omitted the configSections tag)

  <spring>
<context>
  <resource uri="config://spring/objects"/>
</context>
<objects xmlns="http://www.springframework.net"&gt;
  <description>An  example that demonstrates simple IoC features.</description>
  <object name="Person"  type="BOL.BOL.PersonController, BOL.BOL">
    <property name="ThePerson" ref="Person"/>
  </object>
  <object name="Person" type="BobTheBuilder.BobTheBuilder.Builder, BobTheBuilder.BobTheBuilder">
  </object>
</objects>

Okay hope everyone is with me so far - the first object element refers to the class that requires the dependency injection, in our case the PersonController. The child property element refers to the dependency injection point in PersonController, or in our case the ThePerson property. The ref attribute of this element refers to our second object element.

The second object element we set what child object we wish to inject at run time (i.e. TinasModeling.Model or BobTheBuilder.Builder).

Finally the code that puts it all together

    static void Main(string[] args)
    {
        IApplicationContext ctx = ContextRegistry.GetContext();
        PersonController person = (PersonController)ctx.GetObject("Person");

        // Ready to use person with implementation specified in config
        person.NewJob();
        person.PayPerson();
    }

So this will instantiate PersonController based on how we have configured "Person" in our app.config.

So the answer to question one is no (well at least as designed above) - you separate your base implementations completely.

The answer to question two (Is this the best way of architecting this) is probably a little bit subjective - but with distribution and maintenance being your main concern in my opinion the above design meets your needs because the assemblies that are actually doing to heavy lifting is completely decoupled.

Hope I have explained myself well enough.

Dieter G 2009-10-12 21:32:52

ansaurus

tags:

views:

answers:

Inheritance / Architecture

related questions