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 structure with callbacks: Examples: 1. https://en.wikipedia.org/wiki/Visitor_pattern#Dynamic_Visitor 2. https://golang.org/pkg/go/ast/#Walk 3. https://golang.org/pkg/path/filepath/#Walk When you put these two solutions together, you get the original "Visitor Pattern". -- When the language doesn't support overloading, the implementation is usually done such that it doesn't require it. Instead of overloaded starting point in the structure, you'll have an specific one. As a contrived example, you could convert the filepath.Walk into the original(ish) "Visitor Pattern" by having multiple callbacks instead of one or an interface: type Handler interface { HandleError(err error) HandleFile(path string, info os.FileInfo) error HandleDir(path string, info os.FileInfo) error } *In this case, it would be a worse solution and I wouldn't recommend it. * -- I would like to rant about the badness of GoF Design Patterns... as Coplien said, there are no patterns in GoF book [1] <https://stackoverflow.com/a/24664544>. The problem with GoF can easily demonstrated by how hard it is to find good real-world examples of the patterns and that cannot be eliminated with different language. The best Patterns (as described by Alexander) are timeless and guide to a better solution and help you solve a problem that technology cannot fix. [1] Are there any Patterns in GoF? (https://stackoverflow.com/a/24664544) On Thursday, 8 February 2018 07:17:55 UTC+2, Rob 'Commander' 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 of the principle > that a design pattern is just a way to work around shortcomings in the > language. > > -rob > > > On Thu, Feb 8, 2018 at 2:14 PM, Josh Humphries <jh...@bluegosling.com > <javascript:>> wrote: > >> FWIW, it looks like someone else has gone through this exercise: >> https://github.com/tmrts/go-patterns >> >> ---- >> *Josh Humphries* >> jh...@bluegosling.com <javascript:> >> >> On Fri, Feb 2, 2018 at 12:03 PM, <matthe...@gmail.com <javascript:>> >> wrote: >> >>> 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://play.golang.org/p/FRgDBx2CLFf >>> >>> Facade: https://play.golang.org/p/forPdwy9VCi >>> >>> Proxy: https://play.golang.org/p/DFWuDPTOzEP >>> >>> I’m curious how more experienced people rank these and the other >>> patterns. >>> >>> Matt >>> >>> -- >>> 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...@googlegroups.com <javascript:>. >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> -- >> 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...@googlegroups.com <javascript:>. >> For more options, visit https://groups.google.com/d/optout. >> > > -- 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.
