CODEWITHSUNDEEP
javaclassoopdesign-patternsinterface
Jim
Jim

Reputation: 19552

How do you deal when the implementation for an interface method is the same for some classes?

Assume I have defined interface ISomeInterface with methods foo and bar.
E.g. 

public interface ISomeInterface {  
    public void foo();  
    public void bar();  
}

Let's say I have classes A and B that for them it makes sense to both implement the interface. But it also does not make sense to have a different implementation for foo().
Taking into account that deriving A from B or B from A is incorrect/weird is there a standard coding practice for this design?
I assume I could create some utilities class to implement foo() and call it as a delegate but I was wondering if this whole structure can be dealt with differently

Update:
To give a full understanding of my question I stumbled upon this:http://perlbuzz.com/2010/07/why-roles-in-perl-are-awesome.html and I was trying to understand if this feature is lacking from the traditional OO concepts as we use them in Java or not

Upvotes: 5

Views: 160

Answers (5)

gexicide
gexicide

Reputation: 40058

Your edit suggests that your true question is: "Is there an equivalent for Perl roles in Java?"

Since Java 8 introduced default methods in interfaces, interfaces with default methods seem like a very good equivalent for roles. Especially, you can do what you want in your example: Provide a default implementation for foo():

interface ISomeInterface {
    public default void foo(){ /* your default impl goes here */}
    public void bar(); // Abstract, must be implemented by subclasses
}

class A implements ISomeInterface {
    // must only implement bar, can reuse foo's default impl
}

class B implements ISomeInterface {
    // must only implement bar, can reuse foo's default impl
}

If there is a feature about roles I am missing please let me know. Otherwise, I think Java8 interfaces are a quite good surrogate for roles.

Upvotes: 4

Brad
Brad

Reputation: 15879

Alternatively, if you don't want A and B to be tied up by extending an abstract class you can just use composition. This also provides the flexibility to change the IFoo behaviour at run time if you were to inject the FooImpl as part of the constructor. In this example I have just hard wired the FooImpl for brevity.

public class B implements ISomeInterface {

    private IFoo foo = new FooImpl();

    public void foo() {
        foo.doSomethingFooey();
    }

    public void bar() {
        // B specific implementation        
    }
}

public class A implements ISomeInterface {

    private IFoo foo = new FooImpl();

    public void foo() {
        foo.doSomethingFooey();
    }

    public void bar() {
        // A specific implementation
    }
}

Upvotes: 1

The F
The F

Reputation: 42

public abstract class SomeClass implements ISomeInterface {
    public void foo() {
        // I do stuff..
    }
}

public class A extends SomeClass {
    public void bar() {
        // A specific impl. of bar..
    }
}

public class B extends SomeClass {
    public void bar() {
        // B specific impl. of bar..
    }
}

Upvotes: 1

Oliver Watkins
Oliver Watkins

Reputation: 13499

Why not something like this :

public class abstract SomeAbstractClass {  
    public void foo(){
       //implementation
    }  
    public abstract void bar();  
} 

class A extends SomeAbstractClass {

}

class B extends SomeAbstractClass {

}

Upvotes: 1

Seb
Seb

Reputation: 1851

Decided to turn my comment into an answer:

You could use an abstract class rather than an interface:

    public abstract class FooBar {  
        public void foo(){
       //your implementation goes here  
        }

        abstract void bar();  
    } 

    public class A extends FooBar{

        @Override
        public void bar(){

        }
    }

Upvotes: 1

Related Questions