David Lanouette <[EMAIL PROTECTED]> wrote: > Thanks for the reply Barry. > > >They require two, independent, sets of semantics: one for callers > > and another for implementers. > > What do you mean by this?
If you're calling a virtual method, you simply expect it to do something. That's relatively simple, and is the most common documentation. Another slant on the caller's documentation is what the methods in the ancestor class do before calling. It's important to try and avoid holding locks while calling a virtual method, to avoid accidental deadlocks. It might be necessary to set up a try/except block around the virtual method call, in case invariants need to be restored. If you're overriding a method, you need the other documentation - the one that is rarely provided, or if provided is incomplete: what other methods in the ancestor class will call it - and you need to make sure you don't call them, to avoid an accidental infinite loop. You need to know what the state of the class will be - fully initialized, what invariants hold. You need to know what other methods are safe to call and when. > > Inheritance is probably the closest coupling that can be > > created between two classes, and we all know why coupling is > > bad when designing robust, modular systems. Virtual methods > > make coupling even closer, because one class replaces methods > > in the other. > > First, don't get me wrong. I think inheritance should be kept to a minimum. > It's too easy to abuse and not needed nearly as much as it's actually used. > > However, if you are inheriting, the main reason I see for it is to alter the > behavior of the parent class. If you agree with that, doesn't it stand to > reason that you want to make that relative painless? The main reason I use inheritance is for polymorphism - i.e. to expose the same interface (and thus with the same invariants and semantics, in a Liskov Substitution Principle way) but with multiple implementations. One could use interfaces, but interfaces version even worse than base classes. Implementation inheritance is a mixed pill that improves on pure interface inheritance and can reduce code duplication (or at least the forwarding required by aggregation), but of course has coupling implications. > I agree that perf of non-virtual method invocations would be faster (no > v-table lookups, etc.). But, in my experience doing something for perf > reasons only is usually a cop-out. > > Am I missing something? Unless you missed the whole start of my email - i.e. the bit where I point out that it's not for performance reasons "only", or even primarily. -- Barry -- http://barrkel.blogspot.com/ =================================== This list is hosted by DevelopMentor® http://www.develop.com View archives and manage your subscription(s) at http://discuss.develop.com
