They’re kind of like a contract that says, “I have these methods and/or properties and that’s all you know about me”.

Imagine you have a bunch of places in your code where you have a list of things that might be empty and you only want to get the first item out and throw an error if it’s empty. You could write a helper function for that:

function pop_or_throw<T>(items: T[]): T {
    const item = items.pop()
    if (item == null) throw new NotFoundError()
    return item
}

But now you realize you actually do the same exact thing with a bunch of maps. You pop an item off and if it’s empty, you throw an error. So to make this helper function usable everywhere, you can write an interface:

interface Poppable<T> {
    pop: () => T | undefined
}

function pop_or_throw<T>(items: Poppable<T>): T {
    const item = items.pop()
    if (item == null) throw new NotFoundError()
    return item
}

That’s the gist of what interfaces are for. They allow you to think about exactly what your code requires of the things it references and not worry about the specifics of everything else, which often makes it more flexible.

So if you’re writing a function that accepts an object, instead of specifying that object, you can write an interface that only specifies that methods or properties you plan to use. That way, if you make changes to the object or need to switch to a different object, you can leave your other code intact.

They don’t always make sense for small projects, but for large projects they help maintainability a lot. Also, they help when you’re first reasoning through a problem because they force you to minimize what parts of the rest of your system you have to think about while working on a particular part. I’ve seen it talked about like, “when you’re designing a lego, you don’t think about all possible other kinds of legos, you just imagine the connector circles on top”. Those connector circles are the parts that are shared among all of the pieces you care about. It’s your interface.

it's an abstract class without any defined functionality, which allows for use of implementation of multiple on a single class. Basically, what it's saying is 'hey, everything that uses me has to use these functions taking in these inputs, but each of them might do something different with the input, but you can still mass invoke that named function if you need, say, something to loop over everything relevant that implements me and do something with something. I'm also a way of self-documenting responsibility cleanly at the top of a class, because I'm a contract that is designed to simply yell at you if you don't implement your declarations"

lets say you have a button. if you are in front of alice, pressing this button does x. if you are in front of bob, pressing the button does y. If alice and bob both implement the IButtonPressObserver interface with the declared abstract method OnPress(), you can write one function that takes in an IButtonPressObserver in front of you and tells it to run their respective OnPress method instead of one function that takes in alice and one function that takes in bob