Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations Chriss Miller on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

When is a Class overkill?

Status
Not open for further replies.

Foada

Programmer
Feb 4, 2002
1,110
US
Just because everyone seems to enjoy voicing opinions on Fridays, I will try to start a "Friday Discussion Post" today.

When do you draw the line on a Class module? I have seen Classes for a simple "object" say ink which was really only a property of say "pen" but some one thought that "ink" was an object all of its own. I just view it as overkill (because VB6 doesn't fully support inheritance) that some one would make everything a class of its own. Any thoughts? [cheers] If you choose to battle wits with the witless be prepared to lose.
[machinegun][hammer]
 
I would have to agree with you on this, I tend not to create classes for the sake of it.
However I can see the other side. Take your example for instance. A pen may have propeties like width of nib, shape of nib that sort of thing. The ink may have a lot of properties of its own, not just colour. There could be many things that affect how the 'ink' would be drawn on screen. I am all for keeping things as simple as possible.
If the pen object only has ink as a colour then there would be little point in making an ink class.
It will be nice to see other views on this. Any one for building all the objects under the sun?

Matt
 
Foada,

Good question, as ever with a good discussion topic they are grey areas!

IMHO, using the example
pen has some properties say
Type: biro / fountain / roller ball / felt tip etc
BarrelColour: red / brown etc
Owner:
and some methods
Lose() lose pen
Find() find pen again
Break() snap pen in half
Stab() stab enemy with pen
etc
ink also has properties that are not really part of object pen, other than because pen contains object ink.
eg
Viscosity: thickness of ink
InkColour: colour ink
Quantity: Quantity of ink left
and some methods
Leak()
RunOutOfInkAtCriticalTime()
etc

Using FOADA's example, I would use two classes Object Pen which would contain object ink.
I think that the lack of inheritance is a dwonside of VB, but that shouldn't cause people not use nested objects

You could flatten the heirarchy so object pen has methods LeakInk()etc and properties InkColur.

That what I think anyway!!!

Thought please

Matt
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top