From: <ma...@eb...> - 2010-04-02 08:19:18
|
>> Actually ideally (in my opinion) there would be a class hierarchy in >> which >> there is the Atom that by default does no notification, and then for a >> subclass there would be something called a "NotifyAtom", which can be >> used >> for listening/notifying. > > Why would you prefer that subclassing? Just wondering... this is sort > of the idea behind the interface patch... > For me the current hierarchy just seems the wrong way around. I'd rather have classes like Atom not implementing listener functionality and be fast, because these bases classes to me are the obvious developer's pick. Then if you'd want listener functionality, you could use some package with subclasses like 'NotifyAtom' in there. It depends if most people expect notify or no notify to be present in the base class. Alternatively, I'm starting to think that these subclass packages (NoNotify / Debug) are quite a heavyweight a solution anyway. A (probably not so OO) different approach to just have Atom. In Atom, you could have static switches/flags (booleans) to flip on things like notification or debugging. This would eliminate a lot of classes, a benefit perhaps. Mark |