"Dgates" <dg****@spamlinkline.com> wrote in message
news:sd********************************@4ax.com...
(1) I feel "guilty" creating an object. I keep thinking I'd be
"wasting" the computer's time creating an object just for some little
thing, especially when the object would have to be instantiated
thousands of times.
For example:
- a Person object that rolls a die until he's rolled all sides, or
- a Die object that knows which of its sides have been rolled.
You are overly obsessed with performance. Do what makes logical sense, and
then IF you see a demonstrable performance issue, you can tune from there.
And you will quickly learn what is expensive and what is not. You learn by
doing. Don't be afraid to make mistakes -- be willing to make them.
Objects are your friends ... they are not to be hoarded and used when
absolutely necessary, but used intelligently just like variables or anything
your'e already familiar with. A design with thousands of live objects is
common in any non-trivial application.
(2) I coded all my methods as "static." I never instantiate a Roller
object or a CoinGame object.
Am I defeating the whole point of using an OO language here?
Static is appropriate where the method does not need instance data to do its
work, or where you will share data amongst all instances of a class.
(3) I read a coding practice that said something like:
"Once your [blank] gets to be more than 30 lines long, you should
break it into [blank]s."
Was that referring to breaking a method into smaller methods? And is
the goal simply more readable code?
Yes, you probably were reading that long methods should be broken down into
smaller methods. That is almost always good advice. And yes, the primary
goal is more readable / maintainable code. Remember that you (and perhaps
other humans) will have to read the code; and you can only keep a finite
amount of the problem in your head at one time.
(4) When I split a method into several smaller methods, I saw a new
dilemma:
Should I pass the same two or three parameters around every time one
method calls another? Or should I declare (private) class-level
variables to which all of the methods have access?
Depends on the context. Parameters increase calling overhead, as well as
complexity. So, keeping them to a minimum (within reason) is a Good Thing.
If you find yourself passing the same bits of info around between methods
then they are probably better made into private or protected members. Ask
yourself if the info is an attribute of the class, or something internal to
the method. If it has to do with the class, then it should be a class
member.
--Bob