Hi,

First, thanks for your ideas.
One downside with Henry's idea is that the attack function cannot access 
potential struct attributes of the Pitbull or Dog struct (I believe, 
correct me if I'm wrong).
Although there weren't in my example, our code will certainly have struct 
attributes that need to be accessed during the «attack» portion of the code.

So I'd say that goes with Henry's vision, where there isn't a one-size fits 
all approach to those problems.

I think we'll stick with the type-independent function for now as it looks 
like the most versatile

- Julien

On Tuesday, 31 January 2017 07:34:29 UTC-5, Henry wrote:
>
> Hi, 
>
> One thing that I learn about Go is that it forces you to look for a 
> specific solution to your problem, and the same solution usually cannot be 
> applied to other similar problems. However, the same thinking can be 
> carried over from OO to Go. The two dogs share the same preparation method 
> and they differ only in their attack method. Hence, you extract and 
> encapsulate the attack method. Here is an example: 
> https://play.golang.org/p/N1Jq7boNmZ
>
> Bear in mind that it may not work to your actual situation, but you should 
> get the idea.  
>
> On Monday, January 30, 2017 at 11:01:15 PM UTC+7, jul.s...@gmail.com 
> wrote:
>>
>> Hi,
>>
>> Where I work, we are currently experimenting with golang in order to 
>> migrate our existing Perl codebase to golang.
>>
>> Although Perl isn't a pure OO language, it allows for a lot of the OO 
>> patterns to be used. One of the patterns we do use is where a superclass 
>> method wraps a series of call to other methods that can be overloaded by 
>> subclasses.
>>
>> Here is an example of what I mean:
>> https://goo.gl/hTnUI4
>>
>> Now, I've tried to apply the same principle in golang but failed as the 
>> method attack isn't called on the right type:
>> https://play.golang.org/p/ZHhaQhSrms
>>
>> I've scratched my head for a bit to find a solution for this, and the 
>> idea I found was to wrap the prep+attack call in a function that isn't tied 
>> to any of the two structs
>> https://play.golang.org/p/7nK8xEV5rj
>>
>> The example above creates the behaviour I initially expected but I don't 
>> find its as clean as when using the classic OO pattern.
>>
>> Now my question is, how do people usually translate this classic OO 
>> pattern into golang other than the way I found ?
>>
>> Thanks !
>>
>> - Julien
>>
>

-- 
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.

Reply via email to