9

I am creating interface in Java for custom error handler.

Want to pass an argument error object but I need it to be child of Exception class.

Is it okay to use my defined class name in an interface ?

Won't it make it less of an interface in terms of not being dependent on any implementation ?

I try to do something like this:

public class CustomException {
    /* ... Implementation ... */
}

public interface Interface {

    void onError(CustomException ex);

}
10
  • Are you trying to ask if it's okay to inherit another class in an interface?
    – Snoop
    Oct 23 '16 at 20:09
  • @StevieV No. I edited the question, look.
    – 8bra1nz
    Oct 23 '16 at 20:12
  • 1
    @AndresF. It's just an example and can be applied to any OO language about using classes in interfaces.
    – 8bra1nz
    Oct 23 '16 at 20:45
  • 3
    Tell me: is CustomException part of the implementation or part of the interface?
    – user253751
    Oct 23 '16 at 23:51
  • 2
    @nikachx I don't understand what you mean by "safe". In what ways is String safer than CustomException? Why does it matter if CustomException, in turn, has other dependencies?
    – Andres F.
    Oct 24 '16 at 0:16
2

First I have to point out the fact that CustomException doesn't extend Exception so it is not really an Exception.

That said:

If you don't care about Dependency Inversion Principle, then leave it as it is. It's perfectly OK for an interface to depend on concrete classes, for example many interfaces depend on String or Object which are concrete classes. The thing is that we would tend to believe that classes that belong to the Java SDK are more stable (less prone to code-breaking changes) than the ones we write.

In the other hand:

If you want to follow the DIP (which has countless benefits and is my recommendation), then you have to do one of two things:

Option 1

  • Make CustomException abstract
  • Keep void onError(CustomException ex) as it is

Option 2

  • Make CustomException an interface
  • Keep void onError(CustomException ex) as it is

With either of those options you would be conforming to the DIP, since the interface would not depend on any concrete class, only on abstractions.

In a direct application of dependency inversion, the abstracts are owned by the upper/policy layers. This architecture groups the higher/policy components and the abstracts that define lower services together in the same package. The lower-level layers are created by inheritance/implementation of these abstract classes or interfaces. Martin, Robert C. (2003).

  • Agile Software Development, Principles, > Patterns, and Practices. Prentice Hall. pp. 127–131. ISBN 978-0135974445.
9
  • 1
    There's not much difference between accepting an abstract class or a concrete (non-final) class, and the difference to an interface is not much more than that. As long as the instance is passed as a parameter and not hard-coded in your implementation, you have the foundations for DI. Nov 23 '16 at 15:53
  • @JacobRaihle What do you mean by passing an instance hard-coded in the implementation? Nov 23 '16 at 16:32
  • I said "as long as it is passed and not hard-coded". What I mean is that since the Interface interface accepts a CustomException and leaves it up to the caller to provide one, the caller is free to provide any class that extends CustomException even if CustomException is a concrete class - which would not have been possible if Interface was somehow responsible for creating it. This inversion of control, moreso than working with interfaces (although that certainly helps), is what I think DI is all about. Nov 23 '16 at 16:36
  • @JacobRaihle "In a direct application of dependency inversion, the abstracts are owned by the upper/policy layers. This architecture groups the higher/policy components and the abstracts that define lower services together in the same package. The lower-level layers are created by inheritance/implementation of these abstract classes or interfaces." Martin, Robert C. (2003). Agile Software Development, Principles, Patterns, and Practices. Prentice Hall. pp. 127–131. ISBN 978-0135974445. Nov 23 '16 at 16:44
  • What is the point of an abstract class if you can provide a reasonable default? What do you lose by providing that? Don't just quote books, think. Nov 23 '16 at 16:55
2

Tulains is right - interfaces depend on concrete classes all the time. They are only meant to create a contract for their own concerns. That contract can involve taking and returning any kind of data.

Remember that in higher level languages, even primitive types are not so primitive. So you're working with concrete types anyway!

0

I suppose by name, you mean the actual class itself. If you are trying to specify the actual exception class name in order to initialize the corresponding exception through Reflection, this is not the right way to go.

If you want to use a custom class in an interface, you can, of course, use your own classes in your own interfaces. The classes become parts of the public interface of your library/API. Data structures and exceptions are a good example of the classes which are often used by the interfaces.

If you need to use different exceptions depending on the context, then you may be interested in using generics.

3
  • No I don't mean reflection. Yes as you mention Exceptions and data structures can be used in interfaces because they just contain data and are not platform or otherwise dependent on other classes. Thank you.
    – 8bra1nz
    Oct 23 '16 at 20:09
  • 2
    Answers that ask the OP questions... Just ask in a comment, then provide your answer.
    – Snoop
    Oct 23 '16 at 20:41
  • 1
    @StevieV: The first paragraph was more a rhetorical question. And as shown by the comment of the OP, I actually answered the OP's question. Oct 23 '16 at 21:40

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.