Cor Ligthert said:
Strange if you are yourself changing the word "natural" as Nick stated in
"good". While I was only explaining that for me the meaning "natural" has
for me not any meaning inside a design, beside those as done by God or
Nature (depends on what you believe, for me it is Nature) but that has
nothing to do with developing programs.
Ah, I understand now. Sorry, it wasn't very clear before. I suspect
most of the confusion is due to English not being your first language -
which of course is no-one's fault at all.
I think your definition of "natural" is more limited than motst,
however. The meaning I was using is most closely aligned to one of the
ones in my dictionary at home: "as is normal or expected; ordinary or
logical".
As an example, consider a class which needs to represent a number
between 0 and 65535. You *could* represent it as two byte fields. That
would be an unnatural design. The *natural* design would be to use a
single ushort variable. Do you see what I mean now, and how it works
with the meaning quoted above?
If a design is good has for me, is depending on the circumstances it is made
for, what is in one case wrong can be in another situation good. Avoiding
details as using static or whatever in advance can not even come in my mind
by that.
However I will stay saying to a novice who has never used classes
or whatever. "*Try* to avoid static classes".
Except that's not what you said. You said:
<quote>
Just as rule for yourself, if you *can* avoid them, than avoid them.
</quote>
That's different. Even as "try" I would say it's bad advice. Better
advice would be:
"When designing classes, always consider which members should be
instance members (i.e. to do with that particular instance of the
class) and which members should be static members (i.e. to do with the
type as a whole. This is part of learning to design in an object-
oriented fashion."
That doesn't lend a bias towards either side of things, unlike your
advice, which would end up with people making instance members which
should really be static members.
I know myself that I took the first times quickly static classes
(methods properties) while it was better to do not (modular
programming).
And it's entirely reasonable to suggest to people that they should
think carefully about things, but to make people shy away from static
members unnecessarily is a bad idea IMO. I don't like making statement
for the sake of novices which end up causing problems later on.
As well I don't understand why you are writing "us". Is Nick or somebody
else sitting beside you at the moment?
No, but you've already indicated that you agree we both misinterpreted
what you wrote:
<quote>
You both read more in what I wrote than I have ever thought about.
</quote>
I think it's reasonable to write as "us" in a response - I doubt that
Nick would particularly want to distance himself from the last sentence
of my previous post.
