1. 8
  1.  

  2. 5

    I’m not an expert on Java, but why are we putting method implementations into interfaces when we already have abstract class inheritance for (what feels like) this exact thing?

    1. 4

      Interfaces allow multiple inheritance.

      1. 4

        Then it feels like the solution to this is to enable multiple inheritance on abstract classes, rather than adding default implementations to interfaces.

        1. 5

          But that’s not the point of abstract classes. Abstract classes enforce that (1) you must inherit from only one of them and (2) you cannot instantiate them without inheriting them. If you remove either of these constraints you have a regular class, and there definitely are use cases where you want rules 1 and 2 enforced.

          1. 2

            Ok, I’ll think this one over and try to understand.

            1. 2

              I disparaged Java 9 for this too, because it felt like they were further blurring the line between interfaces and abstract classes. After talking with some of my friends (pinging @dsh), it helped me outline some more differences. To expand and maybe give you more to work with:

              abstract classes (to me) feel more class-y, even with these changes. You can’t have final methods in interfaces, nor can you have member variables. As mentioned, you also can’t have multiple inheritance with abstract classes - they are a strictly one-to-one relationship with child classes. Interfaces, on the other hand, are just collections of methods. All you’re doing with a default implementation is telling the compiler to use the given method body if it’s not been specified by the implementor.

              That being said, I think the muddying does harm to people learning the language and the idea of OOP. It gives you two different ways to solve the same problem, and I can see that difference really messing with beginners/intermediates until they fully grasp the philosophy of OOP and when it really is appropriate to use an interface or abstract class.

          2. 1

            No, the solution is default interface methods.

            1. 1

              I know I’m asking for some free mental labor, but I really fail to see why that is the solution.

        2. 1

          I think the intention was to introduce something like Scala’s traits construct without introducing a new keyword. New keywords are practically impossible to add without breaking code.