Geeks With Blogs
Mike Nichols - SonOfNun Technology If I were the captain on a big steamboat...

One of the side-effects of being new out to learning Object Oriented Principles is the propensity to see everything as a subclass of something else. As if all objects shoudl derive from IThing since surely they might ALL have to have some common behaviour, right?!? This is motivated by a GOOD desire...wanting to eliminate duplication of code. So the novice reaches into his toolbox and gets *the* hammer and subclasses, hoping that all inheritors need something like the method he is building.

There are problems with this approach, though such as:

  • A Hierarchy that could get deep is hard to read and maintain
  • The tight coupling that is implicit to inheritance makes it harder to test in isolation
  • Not all attributes in a subclass are that important in the subclasses, so hacks are done to ignore them
  • The objects end up being "clunky" and not lightweight, so they are harder to understand...cohesiveness is easier to lose
  • If an OR/M is being used, the three inheritance strategies need to be supported at least partially...composition is easier to deal with in all the OR/M's I've looked at

Now, an example might help. An Employee is usually a Person right? Therefore, an Employee should inherit from Person, right? After all, you might need to add info like Phone info or Address info to an Employee just like if you were working with any other Person, right? So you'd have some kind of method like AddContactInfo(Phone phone) and then all the happy inheritors can add phone numbers at wiill. Besides, say you have another type of Person called Client...Clients need to add phones, too, right? Since the code to add phones to Client would be the same as adding to an Employee, how can I avoid subclassing?

This is where even just a beginning grasp of Design Patterns are valuable. In this case, a Command Pattern would be the answer to avoid subclassing my Person object into Employee and Client objects, but still avoid the code duplication. Encapsulating the code that adds a phone into a AddPhoneCommand class and passing the info that is needed to execute the command ..

public class AddPhoneCommand

        {

            private IPerson _person;

            private IPhone _phone;

            public AddPhoneCommand(IPerson person,IPhone phone)

            {

                _person = person;

                _phone = phone;

            }

 

            public void Execute()

            {

                person.Phones.Add(phone);

            }

        }

Now I can just get an instance of my AddPhoneCommand and call that from anywhere WITHOUT having to subclass. So long as my IPerson and IPhone contract is met, I can add a phone. The beauty of this encapsulation is now I can get more sophisticated with my AddPhone method like adding Specifications or other rules WITHOUT having to overload my method in an Aggregate class and the looser coupling I got now lets me test in small bites, using mocks and so on.

This is a very basic example of avoiding the Subclass Me reflex by ENCAPSULATION and SINGLE RESPONSIBILITY to behaviour.

So what does my Employee and Client look like? You could use a Decorator on the Person (which could get hairy) or you could just compose the Employee with a reference to Person and , say, a reference to an Employer and a department:

private readonly IPerson _person;

        private readonly IEnterprise _employer;

        private IEnterpriseDepartment _department;

 

        public Employee()

        {

 

        }

        public Employee(IEnterprise employer,IPerson person,IEnterpriseDepartment enterpriseDepartment)

Now I can interact with Person, but not be necessarily bound to any refactorings that happen to Person. I am shileded from its change in my Employee object, at least partially. That's what we are trying to accomplish when we apply these patterns so that our software can be modified without breaking things all over the place. Avoiding inheritance and investigating other methods is one means to this end.

Posted on Wednesday, August 23, 2006 12:59 PM General , C# | Back to top


Comments on this post: The Subclass Me Reflex

# re: The Subclass Me Reflex
Requesting Gravatar...
Good ! thank the author.
Left by google排名 on May 12, 2007 4:31 PM

# re: The Subclass Me Reflex
Requesting Gravatar...
If you are looking for the replica watch and information about it, you came to the right place.
Left by Replica watch on Dec 21, 2007 10:07 AM

# re: The Subclass Me Reflex
Requesting Gravatar...
Looks good!
Go on like this and i will surely visit your site again sometime.
Left by proxy sites on Jan 31, 2009 2:20 PM

Your comment:
 (will show your gravatar)


Copyright © Mike Nichols | Powered by: GeeksWithBlogs.net