What is the best practice (if al all) to implement an interface and have a common property?

Question

What I actually ask, is if there is a way better than using an abstract class if I want all the implementations to have a common (but not static!) property.

For example:

public interface MyInterface{

   public int someProperty = 0;

   public void doSomething();

}

public ClassA implements MyInterface{

   @Override 
   public void doSomething(){...}
}

public ClassB implements MyInterface{

   @Override 
   public void doSomething(){...}
}

Is there a way to create instances of these two implementations and initialize someProperty member of the interface?

Or must I use abstract class instead of the interface in order to initialize this member per each implementing instance?

Java now allows default implementations for its interface members. What prevents you from making the property `static`? — Robert Harvey, Mar 16 '21 at 16:30
Don't define a common property like this. Use interfaces to define type only. Put the common property in a non-instantiable class. — Andy Turner, Mar 16 '21 at 16:31
@RobertHarvey that member *is* static (and final, and automatically public). — Andy Turner, Mar 16 '21 at 16:31
@AndyTurner: "Common but not `static`" feels like a contradiction in terms to me. — Robert Harvey, Mar 16 '21 at 16:33

Basil Bourque · Accepted Answer · 2021-03-17T00:26:28.217

An interface in Java does not have member fields, only methods. (Discussed here.) In other words, an interface defines behavior, but not state.

You can imply a property exists by having JavaBeans-style accessor methods get… & set… declared on your interface.

If you want to ensure each object has its own member field of a certain type with a certain name, then yes, as you suggested, define an abstract class with that field.

Of course you can do both of these: write an abstract class holding the member field that implements the interface requiring the accessor methods. Whether doing both is a good idea or not depends on your specific scenario.

The following is one possible example scenario for having both (a) an abstract class carrying a member field, along with (b) an interface requiring getter/setter accessor methods. I am not entirely sure of the integrity of my logic in this example, but hopefully it conveys the general idea.

Vehicles come in all sorts. Some are legal to use on the public streets, and some are not. One aspect of being street-legal is having a Vehicle identification number (VIN).

Let's define a hierarchy of vehicles.

Vehicle is the grandparent superclass, and is abstract.
GoKart is one child subclass of Vehicle, also abstract, and not legal to drive on streets.
Vin is a record representing our Vehicle identification number (VIN) type.
Car is another child subclass of Vehicle, also abstract. But a car is legal to drive on the street. This abstract class carries a protected class member of type Vin, inherited by any subclasses.
To mark the Car class and its subclasses as being street legal, we define a StreetLegal interface. That interface defines a pair of methods to imply that a property Vin exists on all classes implementing this method.
To pull this all together, we have one example concrete class HondaElement for a particular kind of car.

package work.basil.example.cartalk;

public abstract class Vehicle
{
}

package work.basil.example.cartalk;

// Not street-legal.
// https://en.wikipedia.org/wiki/Go-kart
public abstract class GoKart extends Vehicle
{
    public boolean hasRemoteSpeedControl ;
}

package work.basil.example.cartalk;

// VIN = Vehicle identification number.
// https://en.wikipedia.org/wiki/Vehicle_identification_number#North_American_check_digits
public record Vin(String countryCode, int checkDigit, String serialNumber)
{
    // Add constructor to validate data.
}

package work.basil.example.cartalk;

public abstract class Car extends Vehicle implements StreetLegal
{
    protected Vin vin ;
}

package work.basil.example.cartalk;

public interface StreetLegal
{
    public Vin getVin ( );

    public void setVin ( Vin vin );
}

package work.basil.example.cartalk;

public class HondaElement extends Car implements StreetLegal
{
    public HondaElement ( Vin vin )
    {
        this.vin = vin;   // Accessing member field defined on abstract superclass `Car`.
    }

    @Override
    public Vin getVin ( )
    {
        return this.vin;  // Accessing member field defined on abstract superclass `Car`.
    }

    @Override
    public void setVin ( Vin vin )
    {
        this.vin = vin;   // Accessing member field defined on abstract superclass `Car`.
    }
}

@ArvindKumarAvinash While I agree about the deteriorating situation on Stack Overflow, to be fair, this Question is not an appropriate example. As originally written there was some ambiguity about whether "common property` wording meant a single value shared across instances or a member field where each instance has its own value. Such ambiguity might justify a vote to close based on needing detail/clarity, though asking in a Comment could also be appropriate. Mark Rotteveel soon made an edit to clarify the Question; much improved now over its original condition. — Basil Bourque, Mar 17 '21 at 00:03

What is the best practice (if al all) to implement an interface and have a common property?

1 Answers1