[UPHPU] Objected Oriented question
jtaber at johntaber.net
Tue Sep 18 16:46:27 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.
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
>> 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
> 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.
> UPHPU mailing list
> UPHPU at uphpu.org
> IRC: #uphpu on irc.freenode.net
More information about the UPHPU