Creating new Abstract Method vs Interface Method

Q. Are you still following the principle of Program to an Interface if you are creating abstract methods in an abstract class that is not linked to an interface?

A: An abstract class is also sort of an interface**. It depends how you use it: if you use it as sort of an interface - then you still comply to the principle. If the Abstract class is a technical tool to reuse code between descendants - then this is a sort of a violation.

You can always add an Interface2 extends Interface to reflect the extra functionality of this method. You mentioned this option - and it may make sense if the Abstract class is not "an Interface".

There is a pattern of create an hierarchy interfaces, for different access levels. For instance:

• User interface - a read-only access of user details
• UserMaintainance extends User interface - allowing also to update the user details.

And it seem your case may fall into this definition.

** when programming SPIs, for instance, it is sometimes better to have the interfaces as Abstract classes, so you can maintain backward compatibility to older versions.

Abstract class may be the trick, but as the Growing Object-Oriented Software, Guided by Tests book advises, it would impact the unit testing level:

Do not Mock Concrete class

Usage of Abstract class might not show very explicitly the various potential relationships with its collaborators.

Here's a question about this subject that I ask few times ago, to know further about that.

You would tell me: "But an abstract class is not a concrete class!"
I would call a concrete class, every class that gathers some behaviors in order to emerge an entity.
Abstract class may often implement several methods belonging to various responsibilities, and therefore reduce the explicitness of object's collaborators.

Thus, I would rephrase the "Programming to an interface" by "Programming by roles".