Ok, look.
First of all if you use
size
^ self size
you'll end up in the infinite recursion. You ask size
of object and the size
method asks size
of the object itself and so on.
Now in general about what you should know.
- You should avoid duplication, that's why you are moving similar methods to the parent nodes in hierarchy. If you have a same method in all subclasses, move it into the superclass without hesitation.
- You can just implement methods where they should work. E.i. not write methods with
self subclassResponsibility
at all. Objects should respond to messages that they can understand. Can AbstractDictionary put elements in it? No. Then there can be no method. - It's not nice to do things that I've written in #2 part. Because
- when you browse AbstractDictionary class you get an idea that it should support
at:put:duplicate:
, but the functionality depends on the implementation (aka subclass). - when someone will be implementing another subclass of your dictionary, for example MagicBagDictionary and will forget to implement
at:put:duplicate:
, then during execution he will be gently reminded that this is a subclass responsibility and the method should be implemented. Otherwise he will get an error "message not understood by MagicBagDictionary".
- when you browse AbstractDictionary class you get an idea that it should support
Concerning the size
method again: if you know at some point where you can get the size - do it. For example if AbstractDictionary has instance variable container
that will hold all the element and should be able to tell the size of them - you can implement
size
^ container size
in the AbstractDictionary. But if you have no idea ho the element will be stored and how to calculate their size at that point, you should use:
size
"dictionary size"
self subclassResponsibility
This way AbstractDictionary is saying:
yes, you can get my size, but I have no idea how to calculate it because I'm not complete. But my subclasses should know that, so don't hesitate to ask.