stupid question

[P.Hill]

Andrew McDonagh wrote:
Way back a few day ago I said:

Why would it be an impossible number of classes - wouldn't we have the
same number of classes as we did IFs?

If every IF statement was independant of the all of the others,
a class with 5 IFs might result in 2^5 classes; 100 IFs is very close
to an "impossible number of classes".

YMMV - but I personally favour many smaller classes - they help reduce
duplication, are easier to test stand alone and provide more flexible
re-use.

That is ALSO a good rule. I like small classes and little to no
redundancy too, but that doesn't imply eliminating all conditional logic.

-Paul

 

[P.Hill]

There's also no difference in
performance overhead in creating a new list of listeners, than if we
simply added/removed from a conventional arrayList.

I was just re-reading your post which we seem to have gotten into
tangent about eliminating logic on a tangent about Immutable classes.

What did you mean with this statement?

Are you suggesting that moving all members of a list to a new list
is just as fast as adding on member to a list?

-Paul

 

[Andrew McDonagh]

I was just re-reading your post which we seem to have gotten into
tangent about eliminating logic on a tangent about Immutable classes.

What did you mean with this statement?

Are you suggesting that moving all members of a list to a new list
is just as fast as adding on member to a list?

-Paul

Yes its as fast, however, we don't move all members we simply change
(insert or remove) the linkage between two points within the list.

There's no internal buffer which needs to be kept in sync, we simply
have a series of immutable objects that point to two or less other
objects. The article covers it better than I could re-phrase here (due
to time).

 

[Tony Morris]

Andrew McDonagh wrote:
Way back a few day ago I said:

If every IF statement was independant of the all of the others,
a class with 5 IFs might result in 2^5 classes; 100 IFs is very close
to an "impossible number of classes".


That is ALSO a good rule. I like small classes and little to no
redundancy too, but that doesn't imply eliminating all conditional logic.

-Paul

a) I did not say that mutable types are poor form.
b) I did say that passing or returning a mutable type is poor form, and I
stand by this assertion (it's easily proven). It can 'always' be done
better.
c) Lots of 'ifs' is also poor form. My general rule is that 4 or more should
be replaced by the strategy design pattern (by replaced I mean it would
never occur in the first place - after some practice and acceptance, you
start thinking in terms of strategies instead of nasty control flow). This
also goes on to say that the switch/case is 'always' poor form, since only
constants (not to be confused with a final) are acceptable arguments, and
therefore are better implemented as an enum (1.5 enum or a pre-1.5 enum -
they both compile to the same thing). Pre-1.5 enums are not acceptable in
switch/case.
d) Fear of Adding Classes is a nasty antipattern. In general, you cannot
have too many classes. The exception to this rule is that if you don't
understand why, and you go making classes for the hell of it, you will
likely breaking something (at least, in my practical experience). The number
of classes should never influence a design decision, not even a bit. In
fact, doing so complicates the design almost always (hence, antipattern -
trying to do something but doing the opposite).

Fear of Adding Classes
http://c2.com/cgi/wiki?FearOfAddingClasses

The difference between a final and constant (practical example)
http://qa.jtiger.org/GetQAndA.action?qids=13


--
Tony Morris

JTiger Unit Test Framework for J2SE 1.5
http://www.jtiger.org/
Java Q&A (FAQ, Trivia)
http://qa.jtiger.org/
http://xdweb.net/~dibblego/

 

[P.Hill]

a) I did not say that mutable types are poor form.

Sorry, that was my impression.

b) I did say that passing or returning a mutable type is poor form, and I
stand by this assertion (it's easily proven). It can 'always' be done
better.

Discussing the cases where it is nice form is probably not worth doing.

c) Lots of 'ifs' is also poor form. My general rule is that 4 or more should
be replaced by the strategy design pattern

I was speaking of IFs per class, this is IFs per method. But I agree,
too much logic per method is definitely a smell to examine.

d) Fear of Adding Classes is a nasty antipattern. In general, you cannot
have too many classes.

I heartly agree!

I said:
Andrew was musing about replacing all conditional with
polymorphism when he pondered if

Is it because we can't or don't want too?

Well we can, but I wasn't speaking about
a 'maybe we could add a group of classes to eliminate this
complex logic' kind of discussion. I had brought it up as an example of
a rule that is useful to apply as much as possible and probably more
than many designers choose to, but impossible to apply all the time.
For me that is okay, rules that work 95% of the time are great rules of
thumb. I didn't bring it up because I didn't like eliminating
logic by adding classes in lots of fun cases.

Fear of Adding Classes
http://c2.com/cgi/wiki?FearOfAddingClasses

I'm glad you came back and reminded readers of the problem
of too few classes. I hope no one would use the observation
that all conditionals could be eliminated or hidden in one
place but we really don't want to eliminate all as an excuse
not to add a class.

The number
of classes should never influence a design decision, not even a bit.

I imagine you are thinking of a particular range of values, while
I was speaking of a theoretical end, well beyond some complex, clean
and understanable number. Sorry for the confusion.

The difference between a final and constant (practical example)
http://qa.jtiger.org/GetQAndA.action?qids=13

Wow, Tony, I think you are talking about something else. The
OP got us talking about modifying objects passed in/out and
Andrew and I got off on lots of immutables and now we are discussing the
tension between various rules of thumb or possibly something else.

I don't know about you, but I get the impression we'd actually agree
on most ways to apply such rules as:
- mutating a passed in objects
- reducing a complex or mearly long set of returns in a method.
- reducing complex conditional logic
- generating extra classes to add clarity etc.

I'm ready for a new thread, for I don't know what point
Tony nor Andrew is now going for in this thread and I think we've
addressed the OP.

-Paul