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

I read that one of the Gang of Four has sadly died recently. To me their book seems to be part of American technology history and tradition and I’m glad to have a copy somewhere. And, for structs that need stronger encapsulation (private fields, enforce > invariants at construction time), Go

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

On Wed, Feb 7, 2018 at 5:45 PM, roger peppe wrote: > 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

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

On Thursday, 8 February 2018 09:01:29 UTC+1, Haddock wrote: > > > This might be of interest for you: "Evaluating the Go Programming > Language with Design Patterns > ". > > Interesting read. From the paper: "We found that this was common

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

This might be of interest for you: "Evaluating the Go Programming Language with Design Patterns ". Am Freitag, 2. Februar 2018 18:03:54 UTC+1 schrieb matthe...@gmail.com: > > I’m looking at patterns summarized on Wikipedia from “Design

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

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

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

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

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

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. > >

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

They haven’t seemed necessary in small application development. I'll monitor for real-world examples. There's a few repositories for Go design patterns: https://github.com/tmrts/go-patterns https://github.com/monochromegane/go_design_pattern https://github.com/yksz/go-design-patterns But they

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

I recommend re-writing them using real-world examples, where they really are the "best solution", rather than a facilitated example. Often beginners learn from such facilitated examples and end-up misusing and getting the wrong idea about them. Using realistic examples helps to avoid those

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

I think learning the detail of these Go constructs by transliterating OOP design patterns is good value. For example, above I mention being surprised to learn that a method will override an embedded struct’s function field with the same name. This may be useful for writing minimized Go code in

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

I would rank them mostly unused. There was a point someone made in the past how choosing between design patterns is the equivalent of choosing calling conventions for functions, I don't remember the source, but I agree with the comparison. Most of these are superseded by struct and interface