Re: [go-nuts] “Design Patterns: Elements of Reusable Object-Oriented Software” in Go

2018-02-08 Thread Josh Humphries
On Thu, Feb 8, 2018 at 12:17 AM, Rob Pike wrote: > Isn't the visitor pattern just a way to implement type switch in languages > that don't implement type switch? > > That's certainly how I saw it when using C++. Go has a type switch, and so > has no need for the visitor pattern, a perfect example

Re: [go-nuts] “Design Patterns: Elements of Reusable Object-Oriented Software” in Go

2018-02-08 Thread Egon
In practice it's seen together with two problems: 1. Emulating multiple dispatch with overloading: technically, it doesn't really solve the same problem as GoF described, but it looks a lot like it. Example: https://en.wikipedia.org/wiki/Visitor_pattern#C++_example 2. Navigate a complex structu

Re: Re: [go-nuts] “Design Patterns: Elements of Reusable Object-Oriented Software” in Go

2018-02-07 Thread Bakul Shah
On Thu, 08 Feb 2018 16:17:08 +1100 Rob Pike wrote: Rob Pike writes: > > Isn't the visitor pattern just a way to implement type switch in languages > that don't implement type switch? > > That's certainly how I saw it when using C++. Go has a type switch, and so > has no need for the visitor patt

Re: [go-nuts] “Design Patterns: Elements of Reusable Object-Oriented Software” in Go

2018-02-07 Thread Rob Pike
Isn't the visitor pattern just a way to implement type switch in languages that don't implement type switch? That's certainly how I saw it when using C++. Go has a type switch, and so has no need for the visitor pattern, a perfect example of the principle that a design pattern is just a way to wor

Re: [go-nuts] “Design Patterns: Elements of Reusable Object-Oriented Software” in Go

2018-02-07 Thread Josh Humphries
FWIW, it looks like someone else has gone through this exercise: https://github.com/tmrts/go-patterns *Josh Humphries* jh...@bluegosling.com On Fri, Feb 2, 2018 at 12:03 PM, wrote: > I’m looking at patterns summarized on Wikipedia from “Design Patterns: > Elements of Reusable Object-Orient

Re: [go-nuts] “Design Patterns: Elements of Reusable Object-Oriented Software” in Go

2018-02-02 Thread matthewjuran
Here’s my proxy example with “func (a ProxyCar) Drive()” instead of DriveCar (I didn’t think this would work), and an F-150: https://play.golang.org/p/drDDkx_e0Mp This may fix the signature difference but I see that having an interface type like you suggested for car would allow other data and

Re: [go-nuts] “Design Patterns: Elements of Reusable Object-Oriented Software” in Go

2018-02-02 Thread Josh Humphries
I didn't get a chance to look at all of them, but your Proxy pattern example is incorrect. The idea of a proxy is that the proxy object exposes the same interface as the underlying object, so they are substitutable. In your example, Car is concrete (meaning that callers cannot substitute any othe

[go-nuts] “Design Patterns: Elements of Reusable Object-Oriented Software” in Go

2018-02-02 Thread matthewjuran
I’m looking at patterns summarized on Wikipedia from “Design Patterns: Elements of Reusable Object-Oriented Software” and writing out a few as the equivalent in Go. Visitor: https://play.golang.org/p/A5tNzxMmetH Abstract Factory: https://play.golang.org/p/SWwuX49eysd Factory Method: https://pl