Thanks Burak. I think that makes sense. You can perhaps still think of that
approach as defining the interface "where it's used", even if it's not quite
as close to where it's used as is technically possible. It still has its
caveats,
but it does seem better than defining it where it's implemented, which risks
misunderstanding the purpose of it entirely.
On Wednesday, 27 September 2023 at 12:56:50 am UTC+10 burak serdar wrote:
> On Tue, Sep 26, 2023 at 6:18 AM Jerry Londergaard
> <jlonde...@gmail.com> wrote:
> >
> >
> > Do I need to be re-defining this interface everywhere? I guess
> > an alternative would be to just re-use the `C.DoThinger`, but I feel
> like this doesn't seem right as now A is directly importing C, which seems
> to 'break' the abstraction provided by B:
>
>
> It looks like you can at least get rid of the definition in package A.
> It already has a dependency on B.
>
> If an interface is common enough, you can define it in a common
> package imported by other packages. A common pattern I use is to
> define interfaces and models at the package root level and then create
> additional packages under it for the actual implementation(s). That
> is,
>
> package C
>
> type Something interface {...}
>
> type Model struct {...}
>
> Then, the package C/D would have the implementation of the package.
>
> But at the end of the day, it is subjective. There is no single right
> answer.
>
>
>
>
>
> >
> > ----------------------------------------------
> > package A
> > import (
> > "B",
> > "C"
> > )
> >
> > func Run(dt C.DoThinger) {
> > B.Call(dt)
> > }
> > ```
> >
> > We could obviously define the interface elsewhere in one place, and have
> A, B and C share use of it. This doesn't seem like the end of the world, as
> any of the consumers of that interface can define a new local interface if
> the shared one becomes unsuitable for them.
> >
> > My current implementation (the example given), is to reduce coupling
> between packages. Should I be thinking about this differently? Should I be
> concerned that I'm not adhering to DRY?
> >
> > --
> > You received this message because you are subscribed to the Google
> Groups "golang-nuts" group.
> > To unsubscribe from this group and stop receiving emails from it, send
> an email to golang-nuts...@googlegroups.com.
> > To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/a0436c1c-b24b-4c64-a4bc-12993c25c360n%40googlegroups.com
> .
>
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/7a35321c-d4bd-46a8-b7e3-0aa02bebe2ecn%40googlegroups.com.
