Expanding Slogans

My father often says we're in a time of slogans, in which people tend to keep the quick and easy slogan, forgetting its context. Judging from some things I read, he's right. I'm talking about programming slogans, in special (is what I do, after all) Java slogans.
The origin of this entry are doubts. I read some particular book talking about some particular good practice, the author writes some particular thing I'm not so sure about, and justifies it quoting a bibliography item. My doubts are about the grounds the assertion is made on. This time, I located the source of the quote, checked the context and saw that despite the seemingly justification obtained by the slogan, there's a lot more to it. Inspired by that, this entry is to remind the context of a couple object-oriented slogans that seem to be overused, in particular from the book Design Patterns: Elements of Reusable Object-Oriented Software.

Program to an interface, not an implementation

I've seen this sentence used to justify the creation of one Java interface for each class in an application, including domain classes, JavaBeans by the book.
First things first, it pays to remember this is not a Java programming book, but an object-oriented programming book, so "interface" does not mean "Java interface" but "class contract".
The point of interface-oriented programming is, quoting the book, "to reduce implementation dependencies between subsystems". So, you don't need Java interfaces when they're not different subsystems. If you're implementing an algorithm A and you use a class that is not to be accessed from outside the implementation, you don't need to create a interface for that class because it's the same implementation and subsystem.
Besides, in that context, a Java abstract class is an interface (class contract). If you have typical domain classes then they're only JavaBeans, and a JavaBean is a perfect implementation and interface of everything you'll need.
By the way, after the slogan it talks some more and one of the things that should be empathized is there, when it talks about instantiating concrete classes: if they're different subsystems, there shouldn't be something like IEntityA a = new EntityA(); because that's not really isolating implementation dependencies. Instead of that "new" you are supposed to use - for instance - a Factory.
In conclusion: Program to a contract instead of an implementation, and remember when you're writing part of the implementation or client code.

Favor object composition over class inheritance

Again I have seen this sentence used to justify "don't use inheritance", but what are the reasons between favoring composition?

Use composition when	Use inheritance when
	You need "instance of" and the reused element doesn't implement a Java interface
	You need to override part of the reused implementation
	You need access to protected elements
You need to change reused implementation at runtime
You add functionality (see delegation in that book)	You rewrite functionality

In any case, the main point in understanding this slogan is in the same book: "Inheritance and object composition [thus] work together"