5 ms·

abstract base class != interface

xapata 8y ago
Right, they're even better than Interfaces: both a contract and a partial implementation. No need for an "Interface" when you've got ABCs.
- andreygrehov 8y ago
  I see what you mean, but to me abstract classes are distinct from interfaces. Abstract class answers the question "what an object is?", whereas an interface is about what the object can do.
  - xapata 8y ago
    That distinction is unnecessary.
  - dragonwriter 8y ago
    The distinction between what an object is and what an object can do is an artifact of bad object modelling (specifically, single inheritance OOP.) Any “can do” set has an exactly corresponding “is a thing that can do” set, so there is no logical need for different constructs to model “is” sets and “can do” sets.
    - andreygrehov 8y ago
      Sounds like a controversial statement and I'm not sure how universal true this is. I'll give it a thought. Thank you.
      - xapata 8y ago
        Another way of explaining this is that Interfaces are Java's way to compensate for the lack of multiple inheritance. There's more than one variety of inheritance. Both Python and Java chose implementation-inheritance, meaning that the children get to use not only the interface, but also the implementation of the parent. For some reason, I'm not quite sure why, the Java folks thought that multiple implementation-inheritance would cause too many problems. They still recognized it's useful, so they provided a 2nd form of inheritance that supports multiple parents, interface-inheritance. There are more varieties of inheritance that a language could choose, for example, prototypes like JavaScript.
        andreygrehov 8y ago
        Yes, I'm familiar with all of that, but isn't the Diamond of Death [1] is the exact reason why they did it? [1] https://en.wikipedia.org/wiki/Multiple_inheritance#The_diamond_problem https://en.wikipedia.org/wiki/Multiple_inheritance#The_diamo...
        xapata 8y ago
        People read left to right. That solves all the trivial problems. The harder problems were always vocabulary problems not programming problems. The trouble is that English, and other human languages, have never been as clear or specific as we assume they are when we start writing code. For example, what is a bird? It's a thing that flies? Oh, ostrich, penguin... All these supposed OOP inheritance problems aren't unique to inheritance but to the translation of human language to programming. There's no need to exclude multiple inheritance, because nearly every aspect of programming is afflicted.
kjeetgill 8y ago
Let me help you two out: ABCs are like interfaces in they can be used to enforce properties (like the presence of particular functions) of a class that extends/impliments them; BUT, interfaces can also be used to enforce a particular variable always refers to something with certain properties (without worrying about what it is concretely).

Right, they're even better than Interfaces: both a contract and a partial implementation. No need for an "Interface" when you've got ABCs.

andreygrehov 8y ago
I see what you mean, but to me abstract classes are distinct from interfaces. Abstract class answers the question "what an object is?", whereas an interface is about what the object can do.
- xapata 8y ago
  That distinction is unnecessary.
- dragonwriter 8y ago
  The distinction between what an object is and what an object can do is an artifact of bad object modelling (specifically, single inheritance OOP.) Any “can do” set has an exactly corresponding “is a thing that can do” set, so there is no logical need for different constructs to model “is” sets and “can do” sets.
  - andreygrehov 8y ago
    Sounds like a controversial statement and I'm not sure how universal true this is. I'll give it a thought. Thank you.
    - xapata 8y ago
      Another way of explaining this is that Interfaces are Java's way to compensate for the lack of multiple inheritance. There's more than one variety of inheritance. Both Python and Java chose implementation-inheritance, meaning that the children get to use not only the interface, but also the implementation of the parent. For some reason, I'm not quite sure why, the Java folks thought that multiple implementation-inheritance would cause too many problems. They still recognized it's useful, so they provided a 2nd form of inheritance that supports multiple parents, interface-inheritance. There are more varieties of inheritance that a language could choose, for example, prototypes like JavaScript.
      - andreygrehov 8y ago
        Yes, I'm familiar with all of that, but isn't the Diamond of Death [1] is the exact reason why they did it? [1] https://en.wikipedia.org/wiki/Multiple_inheritance#The_diamond_problem https://en.wikipedia.org/wiki/Multiple_inheritance#The_diamo...
        xapata 8y ago
        People read left to right. That solves all the trivial problems. The harder problems were always vocabulary problems not programming problems. The trouble is that English, and other human languages, have never been as clear or specific as we assume they are when we start writing code. For example, what is a bird? It's a thing that flies? Oh, ostrich, penguin... All these supposed OOP inheritance problems aren't unique to inheritance but to the translation of human language to programming. There's no need to exclude multiple inheritance, because nearly every aspect of programming is afflicted.

kjeetgill 8y ago

Let me help you two out: ABCs are like interfaces in they can be used to enforce properties (like the presence of particular functions) of a class that extends/impliments them; BUT, interfaces can also be used to enforce a particular variable always refers to something with certain properties (without worrying about what it is concretely).