Justin,
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.
Ray Hunter wrote:
I am trying to wrap my head around object oriented programming, but I
am having a difficult time trying to figure out how to code something
like this....
A car manufacturing company makes multiple models of cars (like,
Toyota: Sienna, Tundra, Camry). Each model has a low end, medium end,
and high end version. Each version has a set of options it can choose
from.
Here are my thoughts:
There are at least two classes here (car and option), but I don't know
wether to make subclasses of each of the models. Then do I make
subclasses of each of the models for low, medium, and high end?
I could create an array in each of the subclasses for each of the
options available, but what if there are a hundred options?
What if an option provides more options (like, if you get leather
seats, then you can get them heated if you like)?
When developing with OO languages I like to map out my domain objects
first and see how they will be modeled in the system. I tend to gather
some requirements from the customer and team members to help out with
this process. These domain objects should reflect how users experience
and define the objects in your system. So if needs be, you can break
into other design patterns. Many times testing will influence the domain
objects themselves as well (ie an example of testing system user and
persons).
I would suggest looking at a couple design patterns and becoming
familiar with the concepts and theory behind them and then determine
where you can utilize those patterns in your current application.
If i were creating the system, i would have a hybrid implementation
using many different patterns. For sake of argument i would use
subclasses and composition for most of my domain objects. How they are
created and interact is another ball of wax. Use interfaces, overloading
and overriding when needed and watch out for over extending or over
abstracting your application. That can be detrimental to an application
if overused.
--
Ray
_______________________________________________
UPHPU mailing list
[email protected]
http://uphpu.org/mailman/listinfo/uphpu
IRC: #uphpu on irc.freenode.net
_______________________________________________
UPHPU mailing list
[email protected]
http://uphpu.org/mailman/listinfo/uphpu
IRC: #uphpu on irc.freenode.net
