[UPHPU] Objected Oriented question

[jtaber]

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
> UPHPU at uphpu.org
> http://uphpu.org/mailman/listinfo/uphpu
> IRC: #uphpu on irc.freenode.net
>
>
>