Come for the quick hacks, stay for the epiphanies. | |
PerlMonks |
comment on |
( [id://3333]=superdoc: print w/replies, xml ) | Need Help?? |
To me, there's a world of difference between saying "even though this mock object inherits absolutely no data or behavior from this class hierarchy, it's a member of this class hierarchy" and "this mock object has the same fingerprint as objects of this class and can be used in their place". To me there isn't. I think that's the basis for my confusion. To me the inheritance hierarchy is the exact way you express the relationship between different objects with the same "fingerprint" (which am reading as contract). I don't understand what advantage inventing a different kind of hierarchy gives you. A mock object is not a DBI object. It's not a CGI object. Why not? Seriously :-) Most of my mocks are implemented as full classes and use the @ISA hierarchy to identify themselves. I'd like to avoid forcing composition, delegation, and equivalence relationships into the inheritance scheme. If my substitutable object does not fit within the class hierarchy conceptually, why should I have to lie to the compiler and all future maintenance programmers and say that it does? I don't see how composition or delegation would come into the inheritance scheme. They're not ISA inheritance relationships. If somebody says a car-driver isa car or a library isa book they're just plain wrong. On the other hand equivalence is, to me, what ISA relationships are all about. Can you give an example that shows where ISA wouldn't be appropriate? In reply to Re^3: Class::Interface -- isa() Considered Harmful
by adrianh
|
|