Good style wrt collection classes

V

VisionSet

If we have the familiar business rule 1:many eg Library and its Books

We can have a Book class with a static attribute that collects them. Or
likely a better solution, to have a Library class, where one instance of
which collects the Books.
I expect a good if not the main reason for the latter approach is purer
polymorphism. I've found out the hard way what a pain in the backside static
class members can be.

My OO is getting better all the time, but I'm still a little reluctant to
keep on producing classes 'willy nilly'. I have a bunch of related classes
that all require a small collection of their instances to be present in a
Map, the best solution I can see at present is to have another class for
each, that contains this Map, rather like a lot of special libraries. This
way I can implement interfaces properly etc etc.

Are there any golden rules to this approach, does anyone know of something
surfable that discusses this specifically?
 
V

VisionSet

VisionSet said:
If we have the familiar business rule 1:many eg Library and its Books

We can have a Book class with a static attribute that collects them. Or
likely a better solution, to have a Library class, where one instance of
which collects the Books.

Furthermore, is this top level class a good candidate for a Singleton?
 
A

Andy Fish

IMHO you should definitely not use a static class member to collect all the
books together. A book can exist independently of a library. you should
definitely have a 'book' class and a 'library' class.

look at any significantly sized OO system and you will find hundreds, often
thousands, of classes, and many of these will be trivial. This is just the
way OO tends to work in practice and you should not try to 'work round' this
by violating the purity of your classes.

Also, I don't think you should have 'library' as a singleton. there is more
than one library in the world. Singleton behaviour is something that is easy
to add at a higher level but can never be taken away if implemented in a
lower level class. For instance, if you only ever need one library in your
current application, use a library factory or library manager to make a
singleton library. If you build singleton behaviour into the library class
itself, nobody will ever be able to create more than one library, and this
will limit the reusability in future applications you haven't thought of
yet.

Andy
 
C

Chris Uppal

VisionSet said:
We can have a Book class with a static attribute that collects them. Or
likely a better solution, to have a Library class, where one instance of
which collects the Books.
I expect a good if not the main reason for the latter approach is purer
polymorphism. I've found out the hard way what a pain in the backside
static class members can be.
;-)

My OO is getting better all the time, but I'm still a little reluctant to
keep on producing classes 'willy nilly'.

If the "little" classes have a valid role to play, then don't hesitate.

Also, quite often I've seen a pattern where I've introduced some small class
because it seems to help keep the code tidy, and only *then* realised that
there was real role for it to play. Once the class is there, "in my eye", I
realise that there are several bits of logic scattered around the rest of the
system which really want to be attached to my new class. So the class
plumps-up and becomes a full-time player, and the rest of the code gets simpler
and cleaner. It's always fun when that happens...
I have a bunch of related
classes that all require a small collection of their instances to be
present in a Map, the best solution I can see at present is to have
another class for each, that contains this Map, rather like a lot of
special libraries. This way I can implement interfaces properly etc etc.

That kind of repetition is a bit suspect. Often it signals that you are
working at a lower level of abstraction that would be ideal. In this case, for
instance, it *may* be that you'd be happier introducing a new object with
responsibility for maintaining a Map between classes and the corresponding
collections of "special" instances (probably implemented as normal
java.util.<Whatever>s).

-- chris
 
V

VisionSet

Chris Uppal said:
...
That kind of repetition is a bit suspect. Often it signals that you are
working at a lower level of abstraction that would be ideal. In this case, for
instance, it *may* be that you'd be happier introducing a new object with
responsibility for maintaining a Map between classes and the corresponding
collections of "special" instances (probably implemented as normal
java.util.<Whatever>s).
Thanks for that, actually was coming to the same conclusion, in fact the
real program, I think, was crying out for a factory pattern to centralise
the creation of the collectables. I've gone for the polymorphic factory,
where the abstract factory superclass responsible for the creations has a
subclass as an inner class in every collectible class. This puts the code
in exactly the right place, and I can create the objects in exactly the way
necessary for the individual classes.
I haven't worked out exactly where I'm going to put the resulting
collections yet, but some kind of Map in perhaps a Singleton resource center
is possible.
Ain't OO great!
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,482
Members
44,900
Latest member
Nell636132

Latest Threads

Top