It is a bit unclear, but my educated guess (because no other hypothesis seems to make sense) is that:
- By "inheritance for external [code] reuse" they mean cases where a subsystem exposes (makes publicly available) an abstract base class, which is to be extended by other classes either of this subsystem or of other subsystems. So, in essence, code that uses the base class has knowledge of the fact that inheritance is utilized.
Example:
public abstract class A {};
/* package-private or public */ class B extends A {};
/* package-private or public */ class C extends A {};
- By "inheritance for internal [code] reuse" they mean cases where a subsystem exposes (makes publicly available) an interface, which is internally implemented by a number of classes that are not publicly exposed, and in order to achieve code reuse the subsystem makes use of an also package-private common base class for all the implementing classes. But none of these classes are publicly exposed, so code outside of the package has no knowledge of the fact that the implementations of the interface are extending some common base class.
Example:
public interface I {};
/* package-private */ abstract class A implements I {};
/* package-private */ class B extends A {};
/* package-private */ class C extends A {};
Of course, internal reuse is best, because it allows for maximum flexibility: the subsystem is hiding from the outside world the fact that it is internally using inheritance, so the subsystem can later be refactored to use composition instead of inheritance, and the outside world will not take notice. (Outside code will not even have to be recompiled.) In essence, when inheritance is employed for internal code reuse, the common base class is nothing but a helper.