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,

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

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

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

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

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

[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: