> 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. -- thebigdog _______________________________________________ UPHPU mailing list [email protected] http://uphpu.org/mailman/listinfo/uphpu IRC: #uphpu on irc.freenode.net
