[UPHPU] Objected Oriented question

Ray Hunter bigdog at venticon.com
Tue Sep 18 17:56:02 MDT 2007

> One good way to define classes is that a class should stand on it's own
> and that it is it's own data table.  So a vehicle is certainly a class. 
> Probably a model is a class as well (and inherits from vehicle).  Should
> an option be a separate class ?  Would you use options separately ?  I
> don't think so.  However, an option "package" might be a class. 
> Individual options would be best as lookup array (unless you wanted the
> user to add/remove/edit options - then it needs to be it's own table and
> class).  Honestly, a framework might help you in terms of structure.

imo, a framework should never define your domain objects. a framework
will provide you with a set of tools to help you interact with your
domain objects and provide additional tools to help in the overall
development process. another thing to remember is that your physical
database might never fully resemble your logic database which is a good
thing in OOD. this is where some developers, i think, miss out on the
benefits of object oriented design and and programming. Meaning your
domain object could span multiple tables in your physical database or
logic database.

i have really benefited from uml architecture too. this will allow you
to define some domain objects and communication flows between them.


More information about the UPHPU mailing list