CODEWITHSUNDEEP
javainterfacecouplingloose-couplingconcrete
kelo
kelo

Reputation: 499

Interface method referencing a concrete class as parameter causes coupling?

I was thinking about programming to interfaces and not to concrete classes, but I had a doubt: should any interface method be able to hold references to concrete classes?

Suppose the following scenarios:

1)

public interface AbsType1 {
    public boolean method1(int a); // it's ok, only primitive types here
}

2)

public interface AbsType2 {
    public boolean method2(MyClass a); // I think I have some coupling here
}

Should I choose a different design here in order to avoid the latter? e.g.

public interface MyInterface {} // yes, this is empty

public classe MyClass implements MyInterface {
    // basically identical to the previous "MyClass"
}


public interface AbsType2 {
    public boolean method2(MyInterface a); // this is better (as long as the
                                           // interface is really stable)
}

But there's still something that doesn't convince me... I feel uncomfortable with declaring an empty interface, though I saw someone else doing so. Maybe and Abstract Class would work better here?

I am a little bit confused.

EDIT:

Ok, I'll try to be more specific by making an example. Let's say I'm desining a ShopCart and I want of course to add items to the cart:

public interface ShopCart {
    public void addArticle(Article a);
}

Now, if Article were a concrete class, what if its implementation changes over time? This is why I could think of making it an Interface, but then again, it's probably not suitable at least at a semantic level because interfaces should specify behaviours and an Article has none (or almost none... I guess it's a sort of entity class).

So, probably I'm ending up right now to the conclusion that making Article an abstract class in this case would be the best thing... what do you think about it?

Upvotes: 1

Views: 1777

Answers (3)

JimmyB
JimmyB

Reputation: 12620

If there are no public methods which AbsType would access in MyClass then the empty interface is probably not a good way to go.

There is no interface declaration (contract) for static methods, which otherwise might make sense here.

So, if AbsType is not going to use any methods from MyClass/MyInterface, then I assume it's basically only storing the class object for some other purpose. In this case, consider using generics to make clear how you want AbsType to be used without coupling closely to the client's code, like

public class AbsType3<C extends Class<?>> {

  public boolean method3(T classType) {...}

}

Then you can restrict the types of classes to allow if needed by exchanging the <C extends Class<?>> type parameter for something else which may also be an interface, like <C extends Class<Collection<?>>>.

Empty interfaces are somewhat like boolean flags for classes: Either a class implements the interface (true) or it doesn't (false). If at all, these marker interfaces should be used to convey an significant statement about how a class is meant to be (or not to be) used, see Serializable for example.

Upvotes: 1

Harmlezz
Harmlezz

Reputation: 8078

In my opinion Interfaces are fine for all types where the implementation may vary. But if you define a module which introduces a new type, that isn't intended to have alternative implementations then there is no need to define it as an Interface in the first place. Often this would be over-design in my opinion. It depends on the problem domain and often on the way how support testing or AOP-weaving.

For example consider a 2D problem domain where you need to model a Location as a type. If it is clear that a Location is always represented by a x and y coordinate, you may provide it as a Class. But if you do not know which properties a Location could have (GPS data, x, y, z coordinates, etc.) but you rely on some behavior like distance(), you should model it as an Interface instead.

Upvotes: 1

Peter Wroblewski
Peter Wroblewski

Reputation: 314

I would use interfaces because composition is much better than inheritance. "Should any interface method be able to hold references to concrete classes ?", why it shouldn't? Some classes within package are coupled, it's a fact and common use technique. When you marked this relation in interface then you see on which classes is dependent your implementation. Dependency or composition relations are not inheritance so a i would avoid abstract class.

Upvotes: 2

Related Questions