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.
