P is for Practical | |
PerlMonks |
comment on |
( [id://3333]=superdoc: print w/replies, xml ) | Need Help?? |
From the POD of Class::Interface:
I think inheritance is overused. Scanning various forums and some of the better programming and design books, it appears that other people agree. Consider two classes -- Airport and Arcade. An Airport can contain an Arcade. This is a composition arrangement. If we followed the "traditional" inheritance scheme, any code that wanted to make sure it was accessing an Arcade correctly would check to see if the object is an Arcade. This is a problem for our scheme -- there's no good reason to say that an Airport is an Arcade. We might solve this by creating a superclass of both Airport and Arcade, but that's a mess. I'd personally rather say "Make sure this object can handle any message I can send an Arcade." Since the Airport contains an Arcade, it will just delegate methods like collect_quarters and play_annoying_dance_music to the Arcade it contains. The code that would otherwise do the checking to see if it's dealing with an Arcade object now does something slightly differently. It now checks to see if the object has declared that it implements the same interface as an Arcade object. It's a slight different of semantics, but it opens lots of other doors. Of course, if you do subclass Arcade, things work just fine. A subclass automatically implements the same interface as its parent. Or parents. Or any of its ancestors. I welcome any and all suggestions on the module, from its naming to implementation to tests and documentation. Update: clarified title per Aristotle's suggestion In reply to Class::Interface -- isa() Considered Harmful by chromatic
|
|