Quote:
"The indiscriminate use of GOTOs can result in code that is incredibly difficult to understand, modify, and test. I read a statement on the Internet some months ago, which I thought as wonderful - "Inheritance is the GOTO of the 90s." In other words, all those terrible things you could do with the improper use of GOTOs can now be overshadowed by the terrible things you can do with the improper use of inheritance in the OO paradigm."
--Lee Copeland
Quote:
"The basic problem is that it can be VERY hard to follow the flow of
control in a very deep inheritance tree as method calls go up and down
the tree. It can be even harder to subclass from this tree and
override or redefine (whatever your terminology) without producing all
sorts of unintended side effects (some of which may or may not show up
immediately)."
--Eric Langjahr
Basic Thoughts
I personally have found similar issues with programs that have too many abstractions and inheritance working behind thy back.
However, using pointers excessively in C or in any language can be just as bad though - so inheritance isn't the only bad thing around that causes wild goose chases in source code.
Other Forms of Inheritance?
Sometimes one can "inherit" and reuse existing code by simply making some functions and procedures - I'd guess that the system.pas and the sysutils.pas units are some of the most inherited and reused units of all time - yet they use no or almost zero OOP. It all depends on how you look at "inheritance" and "reuse". If you look at it from a practical perspective, I'd say a lot of non pure OOP code is inherited and reused without actually people recognizing it.
In fact, even though I've never really used them and probably won't find a big need for them, RSS blog feeds allow one to inherit and reuse portions of someone else's blog. Personally I think they are over-hyped, and that this sort of technology is more useful for things like database dumps of inventory (such as Amazon Web Services, although I wished they used a proper square database dump format).
So what really is the definition of inheritance and reuse? Of course true OOP inheritance isn't what I describe above.. true OOP inheritance is when one extends a class without having to type redirection themselves on the keyboard (inheritance in old Records can be done by reusing procedure pointers in records and calling them, but it is more verbose and takes more keyboard effort).
If someone offers me some code in a system unit I'm going to reuse it if it works good. If someone offers me a good class, I will reuse it if it works good. But I try to avoid classes that have been inherited way too far, for way too many purposes.
One thing some OOP programmers don't quite understand is that simple procedures and functions without an instance actually offer a protection/safety. They don't allow inheritance to go to far. They let the API user extend the procedures and functions the ways they want to. Wait a minute, isn't that inheritance?
On the other hand, procedures and functions are too simple for some jobs and there are cases for using OOP inheritance. As stated in the quotes at the top of this page, we are in trouble when people start abusing language features .
Inheritance is a broad and vague term
Even opening up a command line window is inheriting environment settings from the operating system - imagine if you had to reset the environment settings (such as SET PATH=) each time you opened a command line.
Well, I guess I look at "inheritance" in a more broader way than say the OOP consultants would. I think for example some of the Windows API routines are some of the most inherited routines of all time - wrappers around the API are simply inheriting the API. Not really true inheritance according to an OOP consultant, and the WinAPI still kind of sucks - but the point is that portable inheritance doesn't necessarily mean OOP inheritance.
Can SQL queries be inherited
SQL queries can be said to be inherited when one caches a query (or the software caches it for you). You may run an SQL request on the DB and think of the SQL request like a non-inherited procedural call, but in reality DB's are sometimes feeding you cached queries which therefore are in a sense inherited from a previous SQL call that you made a few minutes ago. For example if someone searches the phrase "book" often on your SQL database, you can inherit part of the book query if someone types in "red books" because the "book" query may contain information about the "red books" already in a previous cache.
It would be a waste to go through all the database results from scratch rather than pull them from a previous cache available. So one could inherit red books from books. I realize that this isn't really inheritance according to an OOP consultant.. but try and think outside the box. Inheritance is broader than you think. It's not just about typing out the word "inherited" in your classes and thinking that the world has been saved.
|
