I only just finally wrapped my head around this stuff and forgive me if I
have missed the point of the question but this is what my code has:
type AbstractType alias/struct {}
type abstractthing interface {
DoSomething(interface{})
}
func (a *AbstractType) DoSomething(b AbstractType) {
}
and then in my implementer:
import (
"previousclass/path"
)
type ConcreteType alias/struct {}
func (c *ConcreteType) DoSomething(t ConcreteType) {
}
You have to create a dummy function in the abstract type's source file in
order to use it in the superclass, as it effectively is, in order to use
its generalised functionality, but your app imports the second one, which
sucks up everything from the first and the function bound to the concrete
type overrides the abstract functions in the superclass, allowing you to
generalise part of the superclass and enable you to write a set of
functions with part of the implementation (for example, a tree store) while
letting you change the data type to something else. It's composition, as
opposed to inheritance.
On Saturday, 21 April 2018 14:51:55 UTC+3, Kaveh Shahbazian wrote:
>
> Regarding "Accept interfaces, return concrete types", how can it be
> applied for structs that represent a payload/value?
>
> For example in package first, logger is defined as:
>
> type logger interface {
> Debugf(template string, args ...interface{})
> Errorf(template string, args ...interface{})
> Infof(template string, args ...interface{})
> }
>
> And package first only accepts a logger that implements the logger
> interface.
>
> Now lets assume there is a need for passing a struct too, like some config
> or state.
>
> This causes importing the original package that, that config or state
> struct resides in; while package first is happily accepting other things
> from that package using interfaces.
>
> For example in package second there is some tool that is represented using
> this interface in package first:
>
> type cloner interface {
> Clone() (*second.State, error)
> }
>
>
> As it can be seen, now package first has to explicitly import package
> second, because of the type *second.State.
>
> Currently I break things by renaming the second package to something
> meaningless when importing like:
>
> type cloner interface {
> Clone() (*p2nd.State, error)
> }
>
> But this is not really a work around and package second leaks into the
> scope of package first anyway.
>
> Is there a way to actually achieve this?
>
--
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.
For more options, visit https://groups.google.com/d/optout.
