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?
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?