Clean OO design - Inheritance and Factory Pattern

btyndall posted on Tuesday, June 27, 2006

I'm just wondering within the CSLA or general OO design what the best way to handle "cleaning up" properties for other developers to work off of.  For example:

1) The database design is assumed to be out of your control.  Lets say you are have the Employees table from the Northwind database but you have two additional fields:
EmployeeType char(1) -- which is the single character 'P' or 'F' (parttime / fulltime)
IsSalaried char(1) -- which is the single character 'T' or 'F' (true/false)

2)   If you are using code generation maybe your EmployeeBase class has
Property EmployeeType() as Char ...
'and
Property IsSalaried() as Char ....

3) Then in the Employee business object (inherits from EmployeeBase) - you want your fellow developers to use ... you have:
Enum EmpType
      PartTime
      FullTime
End Enum

Property Overloads EmployeeType() as EmpType ...
'and
Property Overloads IsSalaried() as Boolean ...

My question is if I use the method in #3 to "clean up" the base class.  Then the factory method that creates the Employee class needs to DirectCast down to EmployeeBase and then DirectCast back to Employee before it is returned loaded with data.

 Is this the right way to deal with this situation?  I would like to use code generation and changing the database is not an option.  Is there any negative consequences from Overloading the Properties? from the casting ?  Should I add properties instead?

Any guidance or ideas would be appreciated,
Thanks,
BTyndall

jwooley replied on Tuesday, June 27, 2006

This sounds less like a problem with inheritance and patterns, and more a problem with your code gen implementation. From the sounds of things, you would probably need to move to a meta-driven code gen methodology where the data types and mapping are included in a separate XML file. I recommend checking out Kathleen Dollard's Code Gen book (http://www.bookpool.com/sm/1590591372).

Jim Wooley
http://devauthority.com/blogs/jwooley/default.aspx

ajj3085 replied on Tuesday, June 27, 2006

Hi BTyndall,

Probably the best way to go is to ditch your EmployeeType (char) and IsSaliaried (char) properties, and in your base class define the EmployeeType enum and the two properties (strongly typed).

The code in your DataPortal_Fetch and Insert/Update should translate between boolean and T or F; same goes for the EmployeeType property.

You'll be much better off; there really doesn't seem to be a need for the EmployeeType (char) and IsSalaried (char) in your business model at all.

HTH
Andy

btyndall replied on Tuesday, June 27, 2006

Sounds like I should always fix the problem in the base entity class... I ran into some stuff on the web talking about LSP (http://terrysmith.net/software/dotnet_ebook/chapter6.html) and Inheritance .... seems like I should stay away from breaking LSP.  On a whim I wrote 2 Java classes and Java allows you to change the type of a public property/field also.

Grabbed that exact Kathleen Dollard CodeGen book last week ... and picked up the CSLA VB.NET book this past weekend.  The CodeGen book is really good.  Have alot of stuff written in XSLT all ready to go.  Still working on my Database to XML metadata extraction piece.  Eventually I'll post my efforts.

Thanks again,
BTyndall