Checking my OO technique

[hammerip]

When writing OO code I quite often use the constructor to pass sub class instances which means my sub classes always have a constructor like the C# example below. Is this ok or is their a better way?

class baseClassA
{

protected baseClassB m_ClassB;

public baseClassA(baseClassB classB)
{
m_ClassB = classB;
}

public void DoSomeProcessing()
{

m_ClassB.DoSomeProcessing();
ProcessResult();
}

public abstract void ProcessResult();
}


class subClassA : baseClassA
{

public subClassA() : base(subClassB);


public override void ProcessResult()
{

// some business logic
}

}

 

[BobRodes]

It strikes me that if you reference a subclass in your base class in this way, you're violating rules of encapsulation. Furthermore, I don't really understand what you're attempting to accomplish by doing this. So, tell me exactly why you're doing this and I'll tell you if I think there's a better way to do it.

Bob

 

[hammerip]

I'm trying to write a set of abstract classes which call each other encapsulating the common functionality of a particular task. Each of the classes will alo contain some abstract methods where non-generic code can be plugged in, e.g.

BasePage -> BaseBLL -> BaseDAL

The way I have come up with doing this is; each of the sublasses has to pass the subclass that it references into the constructor of the base class that it inherits from. Does that make sense? It doesn't feel quite right so I'd be grateful for any guidance.

 

[BobRodes]

No, I don't like it much. Generalize out the functions that all of the entities have in common. That's your base class. If you wish to require that certain methods be implemented in subclasses, then you make an abstract base class, which is simply a class in which some of the classes haven't been implemented, and inherit from it, implementing the abstract methods in the subclasses.

So, suppose you set up your structure in some detail and we'll go through it together. I'm still not sure why you are trying to pass a reference of the subclass to the base class's constructor, but I'm getting the feeling that you have something like interfaces in mind. Give me examples of your base class and a couple of your subclasses, with relevant methods of each, and I'll be able to take a better look at what you're up to.

HTH

Bob

 

[hammerip]

I'm happy with the base classes and subclasses. But I'm also trying to encapsulate the relationships between the classes in the base classes, i.e. BasePage calls BaseBll which calls BaseDAL.

When a developer implements a specific instance of this framework they will have to subclass all the base classes, implement the abstract methods, and then 'link up' the sub classes via the base classes. It is the method of linking up by passing the sub classes into the base class constructors that I'm concerned about. I have fleshed out my previous example a bit more to demonstrate what I'm trying to do:


class BasePage
{

protected BaseBLL m_BLL;
protected ArrayList m_Items;

public baseClassA(baseBLL bll)
{
m_BLL= bll;
}

public void PageInit()
{

m_BLL.ListItems();
}

}


class BaseBLL
{

protected baseDAL m_DAL;
protected ArrayList m_Items;


public baseClassA(baseDAL dal)
{
m_DAL = dal;
}

public ArrayList ListItems()
{

m_Items = m_DAL.ListItems();
ProcessResult();
return m_Items;

}

public abstract void ProcessResult();
}


class BaseDAL
{

protected baseDAL m_DAL;
protected ArrayList m_Items;
private DataReader m_Reader;
protected DbCommand m_Command;


public baseClassA(baseDAL dal)
{
m_DAL = dal;
}

public ArrayList ListItems()
{
SetUpCommand();
return ObjectMapper(ExecuteCommand());

}

public DataReader ExecuteCommand()
{
// ADO/Ent Lib stuff
}

public abstract void SetUpCommand();
}


class subclassPage
{

public SubClassPage() : base(new SubClassBLL());

protected Page_onLoad(eventargs)
{

// set-up control, e.g. repeater
repeater.source = m_Items;
repater.databind();
}

}


class subClassBLL : baseClassBLL
{

public subClassA() : base(new subclassDAL());


public override void ProcessResult()
{

// some business logic
}

}


class subClassDAL : baseClassDAL
{

public override void SetUpCommand()
{

// add sp name and params to m_Command
}

}

Thanks for your help.

 

[BobRodes]

Ok, it looks like you're intuiting the concept of polymorphism.

Let's start with a little semantic bridging. I use the term "encapsulate" to mean place a boundary around some specific functionality and expose it to the rest of the application domain via a consistent interface. I'm not sure how you can, given this definition, encapsulate relationships of any kind. I encapsulate functionality, not the means by which different "capsules" of functionality communicate with one another.

Polymorphism, then. Basically, polymorphism will have a base class that is fully abstract (an "interface"), and subclasses that "implement the interface". One then may use the base class as a type, and get "polymorphic" behavior by instantiating that type as any of a number of subclasses.

An example I'm fond of using in class is this. I want to make a bunch of animals. Animals all do certain things, have certain attributes in common, although they do them differently. Let's take two examples, moving and biting.

Class: Animal <<interface>>
Move
Bite

Class: Flea
Implements Animal

Class: TRex
Implements Animal

Note in the above that move and bite are abstract in Animal, and concrete in the implementing classes.

So, as you can see, fleas move differently from trexes, and obviously bite with noticeably different effect. You can write functions that take a pointer to an animal object as an argument and pass it either a flea instance or a trex instance as desired. For example, you could have an Encounter procedure that will evaluate the attack range of the animal instance passed, and call a related Attack procedure if within range, using the specific move and bite methods of the instance passed.

If you play any video games, you might ask yourself how polymorphism is being used in those games. You'll begin to get ideas.

Finally, this is a concise little explanation of polymorphism and encapsulation:

http://dotnetslackers.com/articles/csharp/PolymorphismEncapsulation.aspx

Feel free to post back, of course.

HTH

Bob

 

[hammerip]

I don't think interfaces are suitable in this situation because I am providing common functionality in the base classes and the using the template method design pattern to allow developers to plug-in the pieces of functionality that vary.

Unfortunately, the developers also have to create empty constructors in their subclasses which are purely there to pass in a reference to the next class in the chain. What I want to know is whether this is good practice or not and if there is a better pattern.

 

[BobRodes]

<providing common functionality in the base classes and then...
That's fine. You can use abstract classes (interfaces are of course abstract classes, but we're talking about partially implemented classes here)

<have to create empty constructors in their subclasses...pass in a reference to the next class in the chain.

I think you're pretty much on the right track here. Take a look at this:

http://en.wikipedia.org/wiki/Composite_pattern

and see if the composite pattern is something along the lines of what you're looking for.