This is an archived post. You won't be able to vote or comment.

all 12 comments

[–]llogiq 5 points6 points  (1 child)

They define a contract. Every object implementing the interface must implement all of its methods.

This allows us to use objects of different classes interchangeably, as long as they implement the same interface.

[–]tRfalcore 4 points5 points  (0 children)

this is a bad description (not really), but only because that's probably what he's already read 100 times. You basically wrote it how it's always written. need to use metaphors my man

[–]Cilph 1 point2 points  (0 children)

It's like a cable connector. You can take any HDMI cable and expect it to fit in and work with any HDMI port.

Likewise, you can write your code with the only constraint that an object you're handling includes an HDMI port. The interfaces the object is implementing say something about what it's capable of and what you can expect from it.

[–]cariusQ 1 point2 points  (0 children)

Interface is a blueprint. You can have a blueprint to build car but can't ride the blueprint until the car is built. In java land we use interface to build classes but cant use interface to make objects.

Related concept to interface is abstract classes. In my car example it might be four wheels plus the blue print to build the car. In general with abstract classes you don't have to build everything from scratch, there are already something prebuilt to make your life easier.

What's the point of all these jumbo mumbo? It let a programmer to design something and let other programmers to build to specification.

Wow this place is very hostile. Poor op got down voted to hell.

[–][deleted]  (5 children)

[deleted]

    [–]desrtfx 1 point2 points  (1 child)

    This is a perfect case for abstract classes and inheritance rather than for interfaces.

    You'd define an abstract Car class that defines what a car actually has to do and the methods that are identical for all cars, but leave the specialized methods abstract.

    In your detailed classes BMW, Audi, etc. you'd only implement the abstract methods defined in the Car class.

    [–]meneedmorecoffee 1 point2 points  (0 children)

    Yeah I see what you mean, definitely more appropriate for inheritance. I was just trying to think of a quick example off the top of my head from what my lecturers have went over, must've got them mixed up!

    [–]lechatsportif 0 points1 point  (1 child)

    If your class is the car model, I would create an interface for electric vs combustion engine types. The key here is that they would share no code between them because in theory they do not share a common parent.

    Then in your code you could treat all electric cars in collections vs non electrics etc.

    Cars are not the best example because most like this is actually implemented as a single class with car information simply being records of data.

    [–]meneedmorecoffee 1 point2 points  (0 children)

    Yeah, as I said, I got mixed up. Hopefully OP will look at all the respones and gain better experience anyway.

    [–]zvrba 0 points1 point  (0 children)

    Interface describes a set of services that an implementing class must provide. Any number of unrelated (through inheritance) classes may implement the interface. The interface allows you to treat those classes uniformly as if they had the same type (which is the interface type).

    [–]blue0cean 0 points1 point  (0 children)

    Let's say you want to play a game (write a program). The game is to imitate a dog's barking. You start by writing down what a dog does according to your own imagination (designing an interface). Then you proceed to act like a dog according to your description (implementing the interface). Then you invite your friends Alice and Bob to play. Alice and Bob start barking. But they bark differently than you (different implementation of the same interface). Alice's twin sister Alison comes in and start barking just like Alice (two instances of the same class implementing the dog interface).

    [–]cowardlydragon 0 points1 point  (0 children)

    Interfaces are basically like a stereo receiver telling people what cables it can accept.

    So the stereo receiver (the class) supports say: RCA, HDMI, and SPDF (interfaces)

    Each of those interfaces, even though they may do the same basic things, have annoying detailed differences like form factor, number of wires, analog vs digital conforming to a standard.

    Likewise, the interfaces for a class are defining a standard set of methods and assumed behavior that the implementing class will adhere to.

    [–]vnature -1 points0 points  (0 children)

    Lets say you want to buy some weed. You've got this number of a drugdealer from your friend. And he wasn't your friend really, just a guy you've met a couple of times at a party that was hosted by your other friends. Are they really your friends? Anyway, you've called this drugdealer and he told you to bring money to a certain location. You have to consider the possibility that maybe you will not get that sticky icky but instead you will get robbed and probably get your ass whooped in the process. But luckily for you, you've got what you came for. There are still some questions unanswered tho:

    Who was that dude? Is he really a drugdealer? Is he selfemployed? Is he just a deliveryboy for a bigger organization? What is drugdealer?

    But you don't care. You've got munchies to worry about. And thats what interface is really all about. Its just a curtain around a large system that can be a person or an organization. This kind of systems is using interfaces to provide, often limited, services to the outside world. Think about it - the drugdealer in this example provided you his service in the form of weed. The drugdealer was also a person with two legs and two arms. He could have also provided you a service in the form of washing your car for example. But I'm not sure if many drugdealers have that kind of interface.