General OOP question

[kneejerkreaction]

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?

[Marina]

Re: General OOP question

If a Problem has several properties (e.g. Summary,
StepsToReproduc e,ExpectedResul t) or methods, then it sounds like it needs to
be its own class. If the Problem is just a string containing the problem,
then probably not.

Also, be careful with the term 'subclass'. Typically that refers to
inheritence, not to classes that contain references to instances of other
classes.

"kneejerkreacti on" <kneejerkreacti on@discussions. microsoft.com> wrote in
message news:001A4D02-2E08-42BF-A878-2FE0933D9C54@mi crosoft.com...[color=blue]
> I did not know where else to post this since there is no forum for general[/color]
OOP questions.[color=blue]
> 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[/color]
should be classes and what things should be properties of classes.[color=blue]
> 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[/color]
and properties?

[Nick Malik]

Re: General OOP question

Welcome to OO programming.

Start here:

http://biztalkbum.blogspot.com/2004/07/how-to-learn-object-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

"kneejerkreacti on" <kneejerkreacti on@discussions. microsoft.com> wrote in
message news:001A4D02-2E08-42BF-A878-2FE0933D9C54@mi crosoft.com...[color=blue]
> I did not know where else to post this since there is no forum for general[/color]
OOP questions.[color=blue]
> 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[/color]
should be classes and what things should be properties of classes.[color=blue]
> 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[/color]
and properties?