As someone totally unfamiliar with the GoF patterns, hre's my take. I looked at the wikipedia articles and tried to work out what problem I thought the pattern was trying to address and then wrote some Go code to do that. I'm generally in agreement with those who say that these patterns are there largely to avoid the pitfalls of languages with class-based inheritance.
abstract factory https://play.golang.org/p/syHr7QJ9e2q - anything in Go that returns an interface rather than a concrete type could be considered an abstract factory. facade https://play.golang.org/p/U6DSg5pDC0w - any type that has another type as a member and not much significant logic in its own methods could be considered a facade. proxy https://golang.org/pkg/bufio/#NewReader - any Go function that takes an interface and returns a value that implements the same interface could be considered a proxy. factory method: https://play.golang.org/p/AmQ7lQHAPDy - any function or method that creates and returns an object could be considered a factory. Go doesn't have constructors so this is just normal. visitor: https://play.golang.org/p/w74EhhuAhT5 - I'm not sure that this is a great pattern. Doing a callback for every object in a hierarchy seems fine, but requiring a different method to be implemented for each kind of object seems unnecessary - if you add another kind of object, then all the code using the visitor will break (but that could also be considered an advantage, I guess, as it means your clients are forced to consider all possible kinds). On 6 February 2018 at 23:30, <matthewju...@gmail.com> wrote: >> Your visitor pattern here seems to not be a "visitor" pattern. I would >> think that the Go equivalent would define an interface, and visit based on >> that interface. > > > Here’s what the Wikipedia article says: > >> In essence, the visitor allows adding new virtual functions to a family of >> classes, without modifying the classes. Instead, a visitor class is created >> that implements all of the appropriate specializations of the virtual >> function. The visitor takes the instance reference as input, and implements >> the goal through double dispatch. > > > In my Go conversion the family of classes is the File type. The virtual > function Accept is added to the family without defining behavior. The > Dispatcher is interchangeable and implements Accept for each type of File. > > There's a good possibility that I misunderstood the source example, but I'm > not sure why this isn't a visitor pattern. > >> This isn't really an example of a factory method, because it isn't >> instantiating things of different types. > > > Vars of func types is like a set of classes with only methods. Lately I've > been looking at func types and closures as a pattern that's superior to > interface in some cases. > >> I didn't look at all your examples, but in most cases, it seems like error >> handling, which would be an important part of a Go example, is completely >> absent in the examples given here. > > > Once I dig out the book I’ll try to put together closer to idiomatic > examples. > > Thanks, > Matt > > On Monday, February 5, 2018 at 11:36:42 AM UTC-6, Eric Johnson wrote: >> >> An interesting idea. Some thoughts.... >> >> On Friday, February 2, 2018 at 9:03:54 AM UTC-8, matthe...@gmail.com >> 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 >> >> >> Your visitor pattern here seems to not be a "visitor" pattern. I would >> think that the Go equivalent would define an interface, and visit based on >> that interface. >> >>> >>> >>> Abstract Factory: https://play.golang.org/p/SWwuX49eysd >>> >>> Factory Method: https://play.golang.org/p/FRgDBx2CLFf >> >> >> This isn't really an example of a factory method, because it isn't >> instantiating things of different types. >> >>> >>> >>> 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. >> >> >> I didn't look at all your examples, but in most cases, it seems like error >> handling, which would be an important part of a Go example, is completely >> absent in the examples given here. >> >> Eric >> >>> >>> >>> 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+unsubscr...@googlegroups.com. > 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.
