inheritance, design question

pillesoft posted on Wednesday, August 27, 2008

Dear All,

in my application i'm using a ReadOnlyList with a ReadOnlyBase inherited business object
this is normally displayed in a grid

and there is another class implementation inherited from BusinessBase, which means the same object, but this is not readonly

when a user select a row in a grid to modify, or wants to add a new object a dialog form is opened to display the fields, and here the BusinessBase inherited object is bounded.
the user saves the modification, the dialog form is closed, and the grid is refreshed, now containing the new, or modified record

this is how i planned to use

actually for a special case there are some methods which should have the same code, (like Fetch).
how can i design my classes?

i need a base class, which contains the common methods, then one class should inherit from ReadOnlyBase, other is from BusinessBase.

thank you
Ivan

richardb replied on Wednesday, August 27, 2008

If you have some objects that need to implement the same methods and/or properties, from what you describe sounds to me like you could use Interfaces. Create an interface that defines the common stuff and then your two business objects can just implement that interace.

pillesoft replied on Wednesday, August 27, 2008

yes, but as i know interface only defines methods
i mean the common methods needs to coded physically twice
 
one of the advantage would be less code, and better source handling

Ivan

ajj3085 replied on Wednesday, August 27, 2008

What methods are coding twice?   If you're talking about loading an instance, create an internal third class that can load the common parts of both objects.  Your read only and edit objects can implement a common, internal interface. 

But remember, re-use isn't a goal, because re-use is another word for coupling, and that is something you should usually try to avoid.  Coupling can lead to less maintainable code, meaning more problems later.

pfeds replied on Wednesday, August 27, 2008

What methods does your read-only object class need to implement?  In most cases a read-only class will read in data and display it, without any real need to implement that many methods. Still, this isn't always the case and there are a number of ways you could go about it.  What you don't want is to duplicate logic.

Food for thought:

1) A Person class could have a method CombHair();  Just say you have a PersonInfo class, you could provide a method on it to delegate to the full fat Person class:

public void CombHair()

{

   Person person = Person.GetPerson(this.id);

   person.CombHair();

}

You need to think whether that is necessary.  A button on your UI grid of Person objects could just as easily do the same.

2) If necessary you can expose the CombHair method as a static method on Person, and then call it from PersonInfo.

3) You could create another class to house the common methods.

4) ...etc

pillesoft replied on Thursday, August 28, 2008

Dear All,

thanks for the replies
for the complete reference i attach the two classes.
as you can see the data access (read from db) is the same for both.

but as i'm new to c# and clsa any comments are welcome.

Ivan

pfeds replied on Thursday, August 28, 2008

It looks fine to me. Personally I would leave the Fetch methods as they are.  You're not really duplicating a lot of code, and with this kind of object modelling you do get some overlap.

You could create an internal method on the Section class to handle the fetch, and then call it from the read-only object BUT what if somebody modifies that code specifically for Section - that could break your SectionRO.

Potentially the stored procedure for Section will be expanded to read in multiple result sets (infact it looks like it may already do so?).  With your read-only object you don't really want this additional overhead, especially if you're reading a large amount of SectionRO objects into a list. With that in mind it's likely you could want two different stored procedures, therfore making the two fetch methods different

pfeds replied on Thursday, August 28, 2008

It looks fine to me. Personally I would leave the Fetch methods as they are.  You're not really duplicating a lot of code, and with this kind of object modelling you do get some overlap.

You could create an internal method on the Section class to handle the fetch, and then call it from the read-only object BUT what if somebody modifies that code specifically for Section - that could break your SectionRO.

Potentially the stored procedure for Section will be expanded to read in multiple result sets (infact it looks like it may already do so?).  With your read-only object you don't really want this additional overhead, especially if you're reading a large amount of SectionRO objects into a list. With that in mind it's likely you could want two different stored procedures, therfore making the two fetch methods different

pillesoft replied on Thursday, August 28, 2008

thank you for your opinion of this kind of solution.

after making some stress test i might change the two objects Fetch method, but as i see today there cannot be a large number of sections in a workpack.

anyway thanks again
Ivan