Creating a new method of abstract methods and interface

Question

Q. Do you still follow the principle of the Program for an interface if you create abstract methods in an abstract class that is not associated with an interface?

I already use the interface for all my user interface classes that I created; however, given the reason for the interface, I do not see a direct correlation with the abstract method I want to create and the existing interface.

Usually I just create an abstract method and do it; however, I wonder if I violate the principle of designing a program for an interface or not.

Q. Should I create another interface for this or just stick with an abstract method?

NOTE: This is NOT an interface against an abstract class .

public abstract class BaseClass extends Clazz implements Interface { // 1 out of 4 interface methods are implemented here CustomObj getMode() { ... } // I am actually also thinking of taking that 1 method - getMode() - out of the // interface and implementing it as an implemented method without an interface. // Method that made me ask this question!! abstract CustomObj getDefaultMode(); // Not related to the interface - Interface } public interface Interface { String getFirstNumber(); String getSecondNumber(); CustomObj getMode(); // This one is implemented in the BaseClass, but I think it no longer belongs in this role // CustomObj getDefaultMode(); // This one is not in Interface, but makes be believe I need a new Interface or just have them declared in an Abstract Class. } 

Note. My base class is more designed to simplify code in specific classes. The base class deals with some overridden methods, helper methods, initialization, etc. Therefore, it does not act as an interface, but as your standard abstract class.

Answer 1

I think the wording of the question is too abstract to give a definite answer of yes or no.

In general, there is nothing wrong with abstract classes. The trouble is that people abuse them. How to identify improper use? Rather, what is the proper use of abstract classes?

To do this, we must remember that OO is a way of modeling the “real world”: good designs make models easy to understand, bad designs are difficult to give. Moreover, good OO constructs can be expanded in directions that are likely to extend to the model problem. (I'm not talking about the extends key here.)

What the abstract method says: other methods declared in this class do not make sense without this. While the interface says that for X you need at least these methods.

So, while the abstract method is a way of expressing implementation requirements, the interface defines the role that anyone who implements it can play a role.

Sometimes you need one, another time when you need another.

Answer 2

Q. Do you still follow the principle of a program in an interface if you create abstract methods in an abstract class that is not associated with an interface?

A: An abstract class is also a kind of interface **. It depends on how you use it: if you use it as a kind of interface, then you still follow the principle. If the Abstract class is a technical tool for reusing code between children, then this is a kind of violation.

You can always add Interface2 extends Interface to reflect the additional functionality of this method. You mentioned this option - and it might make sense if the abstract class is not an “interface”.

There is a template for creating hierarchy interfaces for different access levels. For instance:

• User Interface - Read-Only Data Access
• UserMaintainance extends User interface, which also allows updating user details.

And it looks like your case might fall into that definition.

** When programming SPI, for example, it is sometimes better to have interfaces as abstract classes, so you can maintain backward compatibility with older versions.

Answer 3

An abstract class may be a trick, but since it suggests recommendations oriented to object-oriented software, guided by tests , this will affect the unit level of testing:

Do not use the class "Concrete class"

Using an abstract class may not show very distinctly different potential relationships with its employees.

Here is a question about this topic that I asked several times ago to learn more about this later.

You would tell me: "But an abstract class is not a concrete class!"
I would name a specific class, each class that collects some kinds of behavior to create an entity.
An abstract class can often implement several methods that relate to different responsibilities, and therefore reduce the explanatory power of co-authors of objects.

Thus, I would rephrase "Programming to an Interface" using " Programming by Role ".