14

I found the following example in one of the java forum.

interface employee{
    class Role{
          public String rollname;
          public int roleId;
          public Object person;
     }
    Role getRole();
    // other methods
}

I have executed the above code snippet and it is compiling successfully. Which means we can have a class inside an interface.

My question is what is the use of having such classes? Is it any design pattern?

Sangram Nandkhile
  • 17,634
  • 19
  • 82
  • 116
Anil Kumar C
  • 1,604
  • 4
  • 22
  • 43
  • 2
    even if this compile, its not something anyone should do. – memo May 11 '12 at 14:39
  • 1
    possible duplicate of [inner class within Interface](http://stackoverflow.com/questions/2400828/inner-class-within-interface) – NPE May 11 '12 at 14:40
  • 4
    @memo - I disagree. There are situations where this is the right thing to do. – Stephen C May 11 '12 at 14:41
  • 6
    *"...it is compiling successfully"* No, it isn't. It would if you removed the `int` from `public int Role id;` though. – T.J. Crowder May 11 '12 at 14:42
  • mmm i would be very interested in see in wich scenarios, as this would be a whole crime against abstraction and open closed principle. – memo May 11 '12 at 14:43
  • 3
    There is no such thing against "crime" against design principles. Design principles are principles, not laws, and anyone who treats them as if they are "black letter law" is missing the point. – Stephen C May 11 '12 at 14:45
  • 1
    And if you want an example, look at the `java.util.Map` API. – Stephen C May 11 '12 at 14:46
  • 1
    ok crime was the wrong word, but there should be a valid reason to design some code in this way maintaining a solid code, if your code its goin to implement just code violations then there is no point using it. – memo May 11 '12 at 14:47
  • Or, following on from my earlier comment, it would if you removed *either* `int` or `Role` from `public int Role id;` (probably `Role`). – T.J. Crowder May 11 '12 at 14:49
  • java.util.Map have nested interface wich make sense because compact a unit element inside the container protecting it from the outside, i still think this type of code shouldnt be used. – memo May 11 '12 at 14:52
  • Going against a general design principle is not a code violation, if you are doing it for the right reasons. (Or at least, it shouldn't be.) The point of a design principle is the reasoning behind the priciples. For instance, abstraction is about hiding implementation details, but sometimes there is no real point in hiding the details. – Stephen C May 11 '12 at 14:52
  • 1
    @memo - you are entitled to your opinions, but please note that the designers of the Java language and the Java collections framework wouldn't agree with you. Clearly they have a valid reason for doing it, as do other people. And if people have a valid reason for doing something (weighing up the alternatives, etc), then they have every justification in doing it. Which makes your unqualified *"it is not something anyone should do"* comment ... wrong, IMO. – Stephen C May 11 '12 at 14:54
  • not always its about hiding details, abstraction its useful to allow future changes, flexibility and maintainability, obviously if you are sure that your code its not going to change you can specified the design that works for you, but just as a personal opinion i would avoid this type of design. I havent seen this type of implementation in the Collection framework so i dont see your point, althought as a matter of fact java had made a few design mistakes in the past, not in the Collection framework thought. – memo May 11 '12 at 14:59
  • @memo look at the `Map.Entry` class. Can it be any more obvious? – Stephen C May 11 '12 at 15:00
  • mmm i see an interface inside an interface there is no problem with that, am i missing something here? – memo May 11 '12 at 15:03

6 Answers6

9

This code snippet kind of answers your question already. The class Role is used by the employee interface in getRole() method. The designer of the interface decided that this class is so tightly coupled with the interface that it is worth to define it inside that interface to emphasize how important that class is for the interface.

Also it provides semantic namespace for the class: employee.Role. However I see this kind of construct for the first time while static classes defined inside other classes are quite common (for the same purposes as above).

Tomasz Nurkiewicz
  • 334,321
  • 69
  • 703
  • 674
4

The use here is the same as for any inner class. It limits the scope of the class to where it belongs.

In this case the implementer thought that Role was not fit as a top-level class, and put it inside the employee interface. The reason for this is most likely that the intention of Role is to be tightly coupled with employee.

aioobe
  • 413,195
  • 112
  • 811
  • 826
1

The class provides an important part of the interface: A return value for getRole. So it makes sense to define the class within the interface.

It would be a bit more common to define an interface within an interface for this sort of thing (like Map.Entry in java.util), to allow more flexibility when implementing the interface, but you can do the class as well.

T.J. Crowder
  • 1,031,962
  • 187
  • 1,923
  • 1,875
1

There is a slight compilation problem with your example, which I have fixed below:

public interface Employee {
class Role{
      public String rollname;
      public int roleId;
      public Object person;
    }

Role getRole();
}

Aside from that, yes, it compiles. That doesn't mean that doing this is a good idea. It's a further way of name-spacing your Role class, but I think it's rather ugly.

Jon
  • 3,510
  • 6
  • 27
  • 32
0

I wouldn't write such a piece of code, but I think the use is to emphasize the dependency between the class and the interface.

Interfaces are used to define API and in this case, the author may have wanted to say that "these two could not live apart".

Hope this helps.

0

I wouldn't write such a piece of code, but I think the use is to emphasize the dependency between the class and the interface.

Interfaces are used to define API and in this case, the author may have wanted to say that "these two could not live apart".