The State type is just a POGO with no methods. The part that changes is the
implementation of Clone() (State, error) method.
On Sunday, April 22, 2018 at 5:18:00 AM UTC+4:30, Louki Sumirniy wrote:
>
> 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.
