Interfaces and Implementations
Sometimes you want the implementation, sometimes you want the interface.
If you think about people and software, knowing how someone or something works is important. It can help you interact with this thing. If I know my significant other snores at night when they sleep on their back, then maybe I can give them an extra pillow or more room so they roll over on their side and snore less so I can sleep more. I potentially know more about the the thing under inspection than it does, so I can help interact with it better to make my and hopefully their world better.
Sometimes interfaces are useful too. I don’t know how everything in a bank works, I just know that if I deposit money, I should be able to get it back later (maybe with some interest). I don’t have to know how loans work, or interest rates, or how they interact with the Fed to get their own money to help pay me my interest.
There is also a aspect about ourselves where this is important. From the objects’ perspective, if you will. If I am grumpy and don’t want to talk to anyone while walking through the subway back from work, perhaps I put on a meanish demeanor, and people understand that I don’t want any social interaction. Or perhaps I really have no idea what I’m doing at work on a particular task, and I would really benefit me if my boss knew I was working on something I wasn’t very skilled at yet, so they figure out how to give me extra help. Or I’m a baby and my mom knows that I will need a new diaper a few hours after I eat even if I have no clue.
What is an interface exactly? It’s the surface that we present to the outside world. It’s how we want to be interacted with. What is the nitty-gritty details of how something works? That’s the implementation. Sometimes you care, sometimes you don’t.
In software, an interface is a really powerful thing. It lets people who are trying to use me know how I should be interacted with to do so. I have these things you can do to me. I may not exactly do those things, but I should. It’s the expected behavior, a contract. If you do one of these fixed things to me, I will respond in a reasonable fashion.
Knowing how people want to be interacted with can be extremely useful. Seeing a pretty girl at a bar, who's all dressed up and smiling, probably wants to be approached. A programming language class representing a bank account with a "deposit" function that takes an numerical amount probably wants to accept dollars to be added to that account.
Knowing the implementation can also be extremely useful. If I have something in a Java class that implements the List interface will allow appending items and iterating through them, but if I want the 4000th element, then I might definitely want to know I'm using an ArrayList which has O(1) direct memory access so that if I'm walking each element of it, I don't end up accidentally traversing a LinkedList instead which will be extremely inefficient because it has to traverse and re-count each element every time to get to the next item.
Maybe you have a friend who always cares about appearances. So they are always looking like they have everything together on the outside. But they are your good friend, and you know something really bad just happened to them. You know their implementation, that they are potentially hiding that they are very down, so it's really useful to look beyond that interface and offer support.
These are powerful distinctions. How does something want to be interacted with, and how does it actually work. Knowing the distinction with people and software is important.