Many Small Components or Few Bigger?

[Agent Mulder]

I rework my MasterMind applet and have this design doubt:

It is easy to envision the MasterMind board as composed of many very
small components. Each hole where you stick a colored pin is a
component. Each of the small holes where the black and white answer
pins are sticked is a component. When working this scheme, I end up
with over 100 very small components to make up for the game.

Is it better for me to take bigger lumps and work with, say, 15
components or is the above design fine. If it is, what is a practical
limit on the number of components to use?

-X

 

[Michael Borgwardt]

I rework my MasterMind applet and have this design doubt:

It is easy to envision the MasterMind board as composed of many very
small components. Each hole where you stick a colored pin is a
component. Each of the small holes where the black and white answer
pins are sticked is a component. When working this scheme, I end up
with over 100 very small components to make up for the game.

Is it better for me to take bigger lumps and work with, say, 15
components or is the above design fine. If it is, what is a practical
limit on the number of components to use?

It is not. There is no limit BECAUSE you don't work with hundreds of
widgets in one huge class. Instead, you group the widgets together,
e.g. the board (the main GUI class) has a small number of rows,
each row (a lower-level class) consists of a guess area and a result
area, which in turn consists of widgets for the individual pins.
That way, you shouldn't have to work with more than perhaps 10
elements at any given level.

 

[Thomas Fritsch]

I rework my MasterMind applet and have this design doubt:

It is easy to envision the MasterMind board as composed of many very
small components. Each hole where you stick a colored pin is a
component. Each of the small holes where the black and white answer
pins are sticked is a component. When working this scheme, I end up
with over 100 very small components to make up for the game.

Is it better for me to take bigger lumps and work with, say, 15
components or is the above design fine. If it is, what is a practical
limit on the number of components to use?

I personally would stick to the simple design (many small components) as
long as you perceive no memory or performance problems. And I guess
there a no such problems with less than 50 components, but this number
depends on what LayoutManager you use..

A totally different approach would be using a JTable with a custom
TableCellRenderer.
Then even boards with thousands of cells (only needed for very bad
MasterMind players ;-) ) would be no problem, because behind the scenes
the JTable reuses one single component for all cells.

 

[marcus]

Well, I think I'm with you.
I get confused about how a given layoutManager is going to lay things
out on various browsers, and I give up fighting with this sort of thing
very easily. After testing on three different versions of netscape and
5 of IE, I end up using one graphics object, one listener, one set of my
own measurements (distance between rows, stuff like that), and -- whats
the term -- brute force it. its been a long time, but there is a
repaint() that takes a rectangle as a parameter to keep flicker to a
minimum.

Bear in mind if you post here you will get answers that tend to be very
strict, as well as emphasize things like readibility and
maintainability. So . . . when you ask "is it better," you need to
consider what "better" is for the respondents. For me, better is:

a) can I do it quick and does it work,
and
b) does it work under every forseeable situation

but I'm not a pro -- and I get a lot of complaints about top posting.

cheers!
-- clh