6 Replies Latest reply: May 25, 2007 3:58 PM by 796440 RSS

    Some questions related to "Prefer interfaces to abstract classes"

    807606
      After nearly two years' experience with Java, I have almost accept this principle "Prefer interfaces to abstract classes", but still my biggest concern about this is that - it is impossible to add a new method to a public interface without breaking all existing programs, but with abstract class, it is OK. So I want to know, when you guys design your system, how you deal with this.

      two questions related to this:
      1. Why Java is designed to only permit single inheritence, any stories behind the scene? I think some major reasons why "prefer interfaces to abstract classes" is accepted is rooted in this limitation.
      2. Base on the fact that once an interface is out of box and widely implemented, it is almost impossible to change it. So how you guys design your interfaces? Could you share some? In my idea, I would design my interfaces as compact as possible.
        • 1. Re: Some questions related to "Prefer interfaces to abstract classes"
          807606
          two questions related to this:
          1. Why Java is designed to only permit single
          inheritence, any stories behind the scene? I think
          some major reasons why "prefer interfaces to abstract
          classes" is accepted is rooted in this limitation.
          Yes, one of the reasons interfaces are better is that you can only extend one class, but implement many interfaces. Say you have a concrete class that should "implement" two different types. If those types were defined as abstract classes, you could only use one type. You could implement both types if they were interfaces though.
          2. Base on the fact that once an interface is out of
          box and widely implemented, it is almost impossible
          to change it. So how you guys design your interfaces?
          Could you share some? In my idea, I would design my
          interfaces as compact as possible.
          You could extend the interface and start using that if you didn't want to break existing code. You couldn't use that implementation as an Interface1 though, since the new methods only exist in Interface2, so that's not an optimal solution.
          • 2. Re: Some questions related to "Prefer interfaces to abstract classes"
            796440
            After nearly two years' experience with Java, I have
            almost accept this principle "Prefer interfaces to
            abstract classes", but still my biggest concern about
            this is that - it is impossible to add a new method
            to a public interface without breaking all existing
            programs, but with abstract class, it is OK. So I
            want to know, when you guys design your system, how
            you deal with this.

            two questions related to this:
            1. Why Java is designed to only permit single
            inheritence, any stories behind the scene? I think
            some major reasons why "prefer interfaces to abstract
            classes" is accepted is rooted in this limitation.
            It's not much of a limitation.

            There are two kinds of MI--interface and implementation. Usually when people talk about MI, they talk about MI of implementation--code sharing. But that's not what inheritance--single OR multiple--is about. Inheritance is about TYPE. and MI of interface--which we have in Java--let's you define one thing to be of many types. THAT is far more important and useful than code sharing.
            • 3. Re: Some questions related to "Prefer interfaces to abstract classes"
              807606
              two questions related to this:
              1. Why Java is designed to only permit single
              inheritence, any stories behind the scene? I think
              some major reasons why "prefer interfaces to
              abstract
              classes" is accepted is rooted in this limitation.
              Yes, one of the reasons interfaces are better is that
              you can only extend one class, but implement many
              interfaces. Say you have a concrete class that should
              "implement" two different types. If those types were
              defined as abstract classes, you could only use one
              type. You could implement both types if they were
              interfaces though.
              So why java is designed to have this limitation? There may be some arguments before this is settled down. I always like to hear this kind of stories:)
              2. Base on the fact that once an interface is out
              of
              box and widely implemented, it is almost
              impossible
              to change it. So how you guys design your
              interfaces?
              Could you share some? In my idea, I would design
              my
              interfaces as compact as possible.
              You could extend the interface and start using that
              if you didn't want to break existing code. You
              couldn't use that implementation as an Interface1
              though, since the new methods only exist in
              Interface2, so that's not an optimal solution.
              So we may always need to add a new interface when we just want to add a new method.
              • 4. Re: Some questions related to "Prefer interfaces to abstract classes"
                807606
                Sorry jverd , what is MI? interested.
                • 5. Re: Some questions related to "Prefer interfaces to abstract classes"
                  796440
                  So why java is designed to have this limitation?
                  It's not a limitation.
                  • 6. Re: Some questions related to "Prefer interfaces to abstract classes"
                    796440
                    Sorry jverd , what is MI? interested.
                    What have we been talking about that has initials "M" and "I"?

                    Hint: It rhymes with Fultiple Finheritance.