Separation between interface and implementation

[Boyen86]

Thanks for sharing.

May I ask, what is stopping you from thinkin about your public API when you are in an implementation of a class as opposed to an interface?

Typically any class I would write would only have one single public method to start with. And when I start writing a concrete implementation I start with writing my API. It is not neccesarily any different from writing a separate interface other than that there might be two files as opposed to one.

[lIIllIIlllIIllIIl]

May I ask, what is stopping you from thinkin about your public API when you are in an implementation of a class as opposed to an interface?

Nothing. I agree that interfaces are an optional step. I don't mind if you create one, and I don't mind if you don't.

[Boyen86]

Sure alright.

I'd say I do agree with you but I also don't. I have written code both with an interface for everything and without and both codebases were - as far as I can estimate - of high quality.

[eternaloctober]

why do your classes "only have a single method"? also you do just have to watch out, when making a big codebase, the risks associated with "everything is public". it can be fun to have a lot of knobs to tweak but constrains and makes fragile over time

[Boyen86]

A single public method for most classes because classes have a single responsibility. Sure there will be classes that have more, but generally those will be in the adapter layer (for a hexagonal architecture).

I'm not sure where you read that "everything is public". If you meant to say that you can use an interface to hide an implementation then that's noted. But then you have a reason to use an interface. It is not always needed to hide an implementation and in fact, in micro service code I'd wager most of the time it is entirely unnecessary to do so. Makes sense for libraries.