Welcome to OO programming.
Start here:
http://biztalkbum.blogspot.com/2004/...-oriented.html
Next: buy Alan Shalloway's excellent book: Introduction To Design Patterns
....and read it.
Nothing I say on a newsgroup can shed as much light on the topic as this
slim volume can.
As for your Help Desk Ticketing System:
start with the tradition advice, and then refactor your design...
so, start with the nouns...
what kinds of tickets will you have.
What kinds of problems will you track seperately?
Will you have a Knowledge Base? If so, will there be a taxonomy for
categorizing the information in it?
Look for things that are "in common." Look for things that vary. Pull the
common things into base classes. Pull variations into classes that either
inherit or "contain" the common objects (called composition). Draw the
relationships. Factor in design patterns where they simplify the situation.
Note: Common things are not just things... they can be techniques for
creating the object, methods for manipulating the object, or tools for
hiding what's in the object.
Confused? Read the Shalloway book. Leave a budget for more books as
well... you're just getting started...
--- Nick
"kneejerkreaction" <kn**************@discussions.microsoft.com> wrote in
message news:00**********************************@microsof t.com...
I did not know where else to post this since there is no forum for general
OOP questions. I am just getting into OOP after a lifetime of procedural programming.
I'm developing a Help Desk Ticketing System and am struggling with what
should be classes and what things should be properties of classes. So far I have for classes Tickets and People.
I know both will need subclasses.
Some of the ticket properties will be Problem and Solution.
But now I'm wondering if these should be separate classses?
What are the 'rules' for determining what should be classes, subclasses
and properties?