Unfortunately, this anti-pattern is too common. It doesn't hurt until it hurts and when it does hurt, it hurts a lot.
If you are developing frameworks do not provide superclasses that framework users must inherit to use your framework. Inheritance is the one of the tightest forms of coupling you can use in OO. When you force your users to inherit from you, you:
- Make it nearly impossible for users to test their logic independently of your framework
- Make migration away from your framework difficult, or impossible.
The testing issue is subtle, but very real. If you write tests as you develop you notice it immediately. When you inherit code from a framework, it is mixed with your logic. Often you are obliged to run that inherited code with the code that you really want to test, along with all of its dependencies, start up time, etc.
Migration, as well, is a very real issue. If you've written logic important to your domain, there is nothing preventing you from being able to use that logic with other technology - nothing except coupling.
Yes, users of frameworks can guard themselves from that coupling by making their own adapters, but why put them through that? Most of us hate vendor lock-in strategies in business. Framework Superclasses are a very direct form of vendor lock-in.
As a framework designer, you have many other choices: eventing, listeners, and object composition.
Consider them. Thank you.