4 ms·

C++ doesn't have interfaces, so it's quite understandable you wouldn't learn about them if you were learning about C++. Java-as-taught is often ancient Java, f

C++ doesn't have interfaces, so it's quite understandable you wouldn't learn about them if you were learning about C++. Java-as-taught is often ancient Java, from before enhancements like default interface methods. The only non-annoying way to inherit behaviour in ancient Java is inheritance. Even modern Java lacks automatic implicit composition ala Go. Java also encourages large interfaces with many methods. Without any ability to inherit behaviour for those methods, it's often less tiresome to inherit from a class instead. Go, by way of contrast, encourages tiny interfaces with, ideally, one or two methods. In this example, we might suppose that a quintessential "vintage" Java-esque design wouldn't have a single-method "Priceable" interface. It'd have a CartItem interface with hundreds of methods, all of which you'd have to implement - even if only to stub out with exceptions - in order to implement it. So you wouldn't actually use an interface, or else you wouldn't be avoiding all that typing.

manyxcxi 11y ago
I think you're spot on with the lack of a default method in olden days Java. It was certainly the driver behind having an AbstractBaseWhatever class back when. Though there could still be utility in having a base class that had some functionality acting on internal state that was shared by lots of implementations of that. Another use like Priceable and CartItem in modern Java is Connection and AutoCloseable (database connection objects). Anything AutoCloseble can be automatically closed after a try/catch block is done (with some specifics I glossed over on how). And a Connection is that, some specific form of DB connection. You also have a DB ResultSet that is AutoCloseable. So by having another interface extending another, or a class implementing the interfaces you can drive very related functionality on classes that may do very different things. CartItem could extend/implement the one or two method Priceable, along with all its other methods.
neukoelln 11y ago
C++ doesn't have the interface keyword, but that does not mean you cannot have a class that is a pure interface (all methods abstract).
- parenthephobia 11y ago
  C++ doesn't have the interface keyword, but it also doesn't have interfaces. An interface isn't simply a class whose methods are all abstract. It is a distinct kind of type which has no precise analogue in C++ because the language constraints which enable it to exist don't apply in C++. Namely, C++ has multiple inheritance. To abuse a car analogy, this situation is akin to asking why older drivers weren't taught to use cruise control, and the answer being that many older cars don't have cruise control. Whilst it's possible to "emulate" cruise control by simply maintaining constant speed manually, learning to do that isn't the same as learning how to use cruise control.
  - neukoelln 11y ago
    Can you tell me what's the problem with multiple inheritance if your superclasses only consist of pure virtual functions? From [1]: "Bjarne Stroustrup: I had a lot of problems explaining that to people and never quite understood why it was hard to understand. From the first days of C++, there were classes with data and classes without data. The emphasis in the old days was building up from a root with stuff in it, but there were always abstract base classes. In the mid to late eighties, they were commonly called ABCs (Abstract Base Classes): classes that consisted only of virtual functions. In 1987, I supported pure interfaces directly in C++ by saying a class is abstract if it has a pure virtual function, which is a function that must be overridden. Since then I have consistently pointed out that one of the major ways of writing classes in C++ is without any state, that is, just an interface. From a C++ view there's no difference between an abstract class and an interface. Sometimes we use the phrase "pure abstract class," meaning a class that exclusively has pure virtual functions (and no data). It is the most common kind of abstract class. When I tried to explain this I found I couldn't effectively get the idea across until I introduced direct language support in the form of pure virtual functions. Since people could put data in the base classes, they sort of felt obliged to do so. People built the classic brittle base classes and got the classic brittle base class problems, and I couldn't understand why people were doing it. When I tried to teach the idea with abstract base classes directly supported in C++, I had more luck, but many people still didn't get it. I think it was a major failure in education on my part. I didn't imagine the problem well. That actually matches some of the early failures of the Simula community to get crucial new ideas across. Some new ideas are hard to get across, and part of the problem is a lot of people don't want to learn something genuinly new. They think they know the answer. And once we think we know the answer, it's very hard to learn something new. Abstract classes were described, with several examples, in The C++ Programming Language, Second Edition, in 1991, but unfortunately not used systematically throughout the book. " [1] http://www.artima.com/intv/modern.html http://www.artima.com/intv/modern.html
santaclaus 11y ago
> C++ doesn't have interfaces Isn't a class with exclusively pure virtual methods effectively an interface?

manyxcxi 11y ago

I think you're spot on with the lack of a default method in olden days Java. It was certainly the driver behind having an AbstractBaseWhatever class back when. Though there could still be utility in having a base class that had some functionality acting on internal state that was shared by lots of implementations of that. Another use like Priceable and CartItem in modern Java is Connection and AutoCloseable (database connection objects). Anything AutoCloseble can be automatically closed after a try/catch block is done (with some specifics I glossed over on how). And a Connection is that, some specific form of DB connection. You also have a DB ResultSet that is AutoCloseable. So by having another interface extending another, or a class implementing the interfaces you can drive very related functionality on classes that may do very different things. CartItem could extend/implement the one or two method Priceable, along with all its other methods.

neukoelln 11y ago

C++ doesn't have the interface keyword, but that does not mean you cannot have a class that is a pure interface (all methods abstract).

parenthephobia 11y ago
C++ doesn't have the interface keyword, but it also doesn't have interfaces. An interface isn't simply a class whose methods are all abstract. It is a distinct kind of type which has no precise analogue in C++ because the language constraints which enable it to exist don't apply in C++. Namely, C++ has multiple inheritance. To abuse a car analogy, this situation is akin to asking why older drivers weren't taught to use cruise control, and the answer being that many older cars don't have cruise control. Whilst it's possible to "emulate" cruise control by simply maintaining constant speed manually, learning to do that isn't the same as learning how to use cruise control.
- neukoelln 11y ago
  Can you tell me what's the problem with multiple inheritance if your superclasses only consist of pure virtual functions? From [1]: "Bjarne Stroustrup: I had a lot of problems explaining that to people and never quite understood why it was hard to understand. From the first days of C++, there were classes with data and classes without data. The emphasis in the old days was building up from a root with stuff in it, but there were always abstract base classes. In the mid to late eighties, they were commonly called ABCs (Abstract Base Classes): classes that consisted only of virtual functions. In 1987, I supported pure interfaces directly in C++ by saying a class is abstract if it has a pure virtual function, which is a function that must be overridden. Since then I have consistently pointed out that one of the major ways of writing classes in C++ is without any state, that is, just an interface. From a C++ view there's no difference between an abstract class and an interface. Sometimes we use the phrase "pure abstract class," meaning a class that exclusively has pure virtual functions (and no data). It is the most common kind of abstract class. When I tried to explain this I found I couldn't effectively get the idea across until I introduced direct language support in the form of pure virtual functions. Since people could put data in the base classes, they sort of felt obliged to do so. People built the classic brittle base classes and got the classic brittle base class problems, and I couldn't understand why people were doing it. When I tried to teach the idea with abstract base classes directly supported in C++, I had more luck, but many people still didn't get it. I think it was a major failure in education on my part. I didn't imagine the problem well. That actually matches some of the early failures of the Simula community to get crucial new ideas across. Some new ideas are hard to get across, and part of the problem is a lot of people don't want to learn something genuinly new. They think they know the answer. And once we think we know the answer, it's very hard to learn something new. Abstract classes were described, with several examples, in The C++ Programming Language, Second Edition, in 1991, but unfortunately not used systematically throughout the book. " [1] http://www.artima.com/intv/modern.html http://www.artima.com/intv/modern.html

santaclaus 11y ago

> C++ doesn't have interfaces Isn't a class with exclusively pure virtual methods effectively an interface?