- Alright, I just wanna sum up everything we just did
in this composition around design,
and just kind of hear the cliff notes of everything we did
and things you should be thinking about
when we start moving from the concrete into behavior.
We start decoupling our concrete solutions.
Now, interfaces are very, very powerful, right?
I don't want pollution,
but here's some really interesting things.
Interfaces are gonna give our program structure.
They're gonna encourage design by composition,
and I showed you how that composition works.
And they also allow us to enable
and enforce these clean divisions between components,
whether these, and a lot of times,
these components are gonna be these packages.
We're gonna start talking about
package on design eventually,
and we're gonna really talk about decoupling,
and the interface can really help with decoupling.
Because remember, I can define an interface
that satisfies your concrete values.
And you can define interfaces that, my concrete values,
and therefore, these interfaces which are
isolated defined within the packages themselves
can create very clear divisions.
And we have really nice layers of decoupling
through convention, not configuration.
Now again, when we talk about decoupling,
we're really trying to reduce dependency.
We're trying to decouple components
and packages as much as we can.
And that's always going to lead
to correctness, quality, and performance.
It's going to allow code base to grow over time
and not suddenly come to a halt.
And we've seen that already by
some big projects in the Go community, okay.
Remember when it comes to grouping,
we don't want to group by what we are.
We want to group by what we do.
We don't want to talk about who we are.
That's configuration, right.
Our parents made us who we are.
But we, individually, decide what we want to do.
And that's how we want to group things.
Or I want to be around people
who are not necessarily like myself from a DNA perspective,
but who like to do the same things that I do.
We want to focus our code around
that level of diversity, okay.
Level of diversity.
So that interface is going to help
our code decouple from change.
It's going allow our code to maintain decoupling
between packages or components.
Or anyway, we got to really do our best
to understand what is going to change in our code
and try to decouple that.
And it really helps if you start
with that concrete implementation.
That same exercise we went to, okay.
The same exercise.
And if it's not clear what an interface is doing for us,
the benefit is not clear, I want us to stop.
I want us to learn more,
and I want to question those things, okay.
And the biggest thing here that we can do
is really try to design code and write APIs
that defend against fraud and not protect against accidents.
To really focus on the idea
that we want to design APIs that are hard to misuse.
I mean, JBD from Google
said these two things better than I ever could.
"A good API is not just easy to use
but also hard to misuse."
And, "You can always embed but you cannot always decompose
big interfaces once they are out there."
"Keep interfaces small."
Compose interfaces as you need them.
This is really going to help you design better coding Go,
not only today, but for tomorrow.