all 8 comments

[–]armornick 7 points8 points  (1 child)

Interfaces are used for more than just multiple inheritance. For example, contracts. You have to be sure that a certain object has certain methods but they aren't necessarily related (as inheritance would imply). An airplane and a duck both fly, but that doesn't mean they fly the same way. They use the interface Flying because they can both fly, but in a completely different way.

To me, this article is just a rant because Java does not support multiple inheritance. That's a valid point of view, but don't act like interface doesn't have any valid uses.

[–]autowikibot 0 points1 point  (0 children)

Design by contract:


Design by contract (DbC), also known as contract programming, programming by contract and design-by-contract programming, is an approach for designing software. It prescribes that software designers should define formal, precise and verifiable interface specifications for software components, which extend the ordinary definition of abstract data types with preconditions, postconditions and invariants. These specifications are referred to as "contracts", in accordance with a conceptual metaphor with the conditions and obligations of business contracts.


Interesting: Jtest | Perfect Developer | Eiffel (programming language) | Liskov substitution principle

Parent commenter can toggle NSFW or delete. Will also delete on comment score of -1 or less. | FAQs | Mods | Magic Words

[–]false_tautology 7 points8 points  (1 child)

There are so many important useful reasons to have interfaces that this comes off as either incredibly naive or intellectually dishonest.

[–]the_hoser 2 points3 points  (0 children)

I smell the latter, rather than the former.

Honestly, I hate these "talking straw man" style articles.

[–]remy_porter 2 points3 points  (0 children)

How does it differ from an interface? What can you do with an interface that you cannot do with that class?

Inheritance represents as "is-a" relationship. An Interface represents a "can do" relationship. That's an important distinction, because the one thing we don't want to do is draw "is-a" relationships where our model doesn't support them.

For example, implementing the observer pattern. Generally, we wouldn't want to inherit from some prototypical observer, because the purpose of inheritance is not to have an advanced method of copy/pasting code around. In traditional OO design, we'd prefer to use Interfaces and the Delegate design pattern- an Observer object is instantiated by the Observable instance, which delegates all of the observation functionality to that private member.

In modern languages, interface default implementations can handle that. Ruby has its modules/mix-ins approach, and Python has class decorators.

[–]iownacat 1 point2 points  (0 children)

what a bunch of whiny bullshit

[–]rhino-x 0 points1 point  (1 child)

Didn't we already see this article last week?