I have seen some Ruby code where the base class was used just for the purpose of providing an interface (JAVA style). From what I have seen of Ruby this is not needed.
Am I correct in my thinking?
Thanks!
Example:
class MyBaseClass
def doStuff
# empty place holder
# or
# throw an error here - not overridden!!
end
end
class MyDerivedClass < MyBaseClass
def doStuff
# overridden
return someValue
end
end
reply (847 Bytes)
stedak@charter.net wrote:
I have seen some Ruby code where the base class was used just for the purpose of providing an interface (JAVA style). From what I have seen of Ruby this is not needed.
Am I correct in my thinking?
Yes.
The pros and cons of this and other approaches to interfaces, protocols, object signatures, etcetera may be found be searching the ruby-talk archives for keywords such as "duck typing," "interfaces," and "strong typing." Oh, and "hashpipe" 
It comes up, oh, every so often.
I've seen (and used) this technique where the developer wants some assurance that another class responds to at least some given set of messages. Simply telling other developers to extend or derive from an "abstract" class, and to override the default methods, is a simple way to guide the creation of a class that provides appropriate behavior.
(But, although I've done this, I'm not convinced this is a good thing or the best way to do this, and recent discussions have given plenty of food for thought.)
Another way is to simply document the message names and expected parameters. Ruby typically does not bother with lineage or ancestry; rather egalitarian in that respect.
Unless you are dealing with code that is explicitly inspecting the class of a given object, all that matters is behavior, however that comes about.
But please dig up past threads on this, as there are some very good ideas in there.
James