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

[matthewjuran]

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 has its own pattern: the functional 
> option pattern.


I’m not sure how that’s related to encapsulation, but this options problem 
is appearing in the standard library because of cancellation via a context 
var. In the Go 2 proposals I’ve been suggesting another pattern where a 
struct type contains shared pointers and read-only values, is called by 
value instead of by pointer by methods, and has fields that are set in the 
value copies for optional behavior.

I haven’t recognized the functional option pattern before (my takeaway is 
“make use of … in API design”) and I’ll keep it in mind. Maybe it’s a good 
solution to this context problem.

Isn't the visitor pattern just a way to implement type switch in languages 
> that don't implement type switch?


The visitor does double dispatch where the behavior of each type can be 
swapped out. Maybe a type switch into a type switch would be equivalent.

This might be of interest for you: "Evaluating the Go Programming Language 
> with Design Patterns".


I’m seeing overuse of interface, but I’ll read this paper in more detail.

The Wikipedia article on Anti-patterns is interesting: 
https://en.wikipedia.org/wiki/Anti-pattern. I learned what “bike shedding” 
means, and I think that pattern would be better described as “working on 
the bike shed”.

Thanks,
Matt

On Thursday, February 8, 2018 at 9:22:23 AM UTC-6, Joshua Humphries wrote:
>
> 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 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.
>>
>
> Some are targeted specifically at C++/Java -- not due to class-based 
> inheritance but to language/syntax limitations. For example the builder 
> pattern is meant to make construction of objects more readable than 
> overloaded constructors/factories with telescoping argument lists. Go has 
> less need for this because of its struct literal syntax. And, for structs 
> that need stronger encapsulation (private fields, enforce invariants at 
> construction time), Go has its own pattern: the functional option pattern 
> .
>
> They certainly aren't all there to avoid pitfalls of class-based 
> inheritance. Many are intuitive solutions to certain classes of problems: 
> one could easily write code that adheres to one of these patterns without 
> even realizing it (adapters, facades, decorators, interceptors, commands, 
> strategies, flyweights, iterators, observers, DSLs). Admittedly, some are 
> less powerful/expressive without class-based inheritance, so less 
> applicable to Go. But, as alluded to in the previous paragraph, Go has some 
> of its own patterns.
>
>
>> 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.
>>
>
> This isn't quite right. Your example is just a parameterized factory 
> method. This pattern is about the factory itself being abstract. Here's a 
> re-worked example: https://play.golang.org/p/joSYzhMeS0n
> This pattern is a specialization of the strategy 
>  pattern.
>  
>
>>
>> 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.
>>
>
> And if that facade implements a particular interface then it is also an 
> example of the adapter  
> pattern. More adapter examples: bytes.NewReader() and strings.NewReader(). 
> They adapt []byte or string to the io.Reader interface.
>  
>
>>
>> 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.
>>
>
> This describes the decorator pattern more than the proxy pattern. Usually, 
> a proxy isn't just a wrapper (like a decorator is) -- the proxy object is 
> some form of stand-in for some other resource, typically remote. RPC is a 
> much better example of the proxy pattern (like the "net/rpc" package, but 
> also things like gRPC). Sometimes proxies also add functionality (like the 
> decorator pattern), translate protocols (a la the adapter pattern), or 
> perform 

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

[Josh Humphries]

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

Some are targeted specifically at C++/Java -- not due to class-based
inheritance but to language/syntax limitations. For example the builder
pattern is meant to make construction of objects more readable than
overloaded constructors/factories with telescoping argument lists. Go has
less need for this because of its struct literal syntax. And, for structs
that need stronger encapsulation (private fields, enforce invariants at
construction time), Go has its own pattern: the functional option pattern
.

They certainly aren't all there to avoid pitfalls of class-based
inheritance. Many are intuitive solutions to certain classes of problems:
one could easily write code that adheres to one of these patterns without
even realizing it (adapters, facades, decorators, interceptors, commands,
strategies, flyweights, iterators, observers, DSLs). Admittedly, some are
less powerful/expressive without class-based inheritance, so less
applicable to Go. But, as alluded to in the previous paragraph, Go has some
of its own patterns.


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

This isn't quite right. Your example is just a parameterized factory
method. This pattern is about the factory itself being abstract. Here's a
re-worked example: https://play.golang.org/p/joSYzhMeS0n
This pattern is a specialization of the strategy
 pattern.


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

And if that facade implements a particular interface then it is also an
example of the adapter 
pattern. More adapter examples: bytes.NewReader() and strings.NewReader().
They adapt []byte or string to the io.Reader interface.


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

This describes the decorator pattern more than the proxy pattern. Usually,
a proxy isn't just a wrapper (like a decorator is) -- the proxy object is
some form of stand-in for some other resource, typically remote. RPC is a
much better example of the proxy pattern (like the "net/rpc" package, but
also things like gRPC). Sometimes proxies also add functionality (like the
decorator pattern), translate protocols (a la the adapter pattern), or
perform routing/multiplexing/demultiplexing.

Another related pattern is the interceptor pattern (aka
chain-of-responsibility
).


>
> 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.
>
>
This statement describes "factory method", but is not at all what the
factory method pattern is about. This pattern is specific to class-based
inheritance. The idea is to create a virtual/abstract factory method that
sub-classes override to return different sub-types/implementations.

Since Go does not have class-based inheritance, the closest I could
envision is "override" behavior via a function field. Here's a take on it
based on the example in the wikipedia page
:
https://play.golang.org/p/EnZ4sRFdmyT



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

This one also is more suited to class-based inheritance as there is usually
a base class implementation that has a no-op implementation for all
callbacks. That way, the code implementing the visitor is not broken
whenever a new method is added to the visitor. (In Go, you could embed a
no-op visitor, so that you only need to implement the subset of applicable
methods.) For what it's worth, adding other kinds of 

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

[Volker Dobler]

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 and that having to use
 different names was inconvenient — there is no naming
 convention for multiple different factory methods, so
 clients wishing to instantiate an object must either guess
 *or check the documentation*." 
[Schmager, Cameron, Nobel, l.c., sec 4.1, page 5, emphasis mine]

It seems checking the documentation is something one should
not be required to do. And I now that lots of developers never
take a look at documentation. But why? What's wrong with
reading a few sentences or skimming a 3 page manual?

V.

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

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

[Haddock]

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 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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[roger peppe]

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

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

[matthewjuran]

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

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

['Eric Johnson' via golang-nuts]

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.

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

[matthewjuran]

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 don't have real-world examples.

Matt

On Monday, February 5, 2018 at 4:17:15 AM UTC-6, Egon wrote:
>
> 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 problems (to some degree).
>
> On Friday, 2 February 2018 19:03:54 UTC+2, 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
>>
>> 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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Egon]

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 problems (to some degree).

On Friday, 2 February 2018 19:03:54 UTC+2, 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
>
> 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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[matthewjuran]

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 
cases where a proxy, interceptor, or decorator pattern is called for.

My question could be rephrased as “what problems are most important to you 
that these design patterns were made to solve?” I do think keeping the code 
solution as close to the problem geography as possible is right, and maybe 
design pattern thinking enables distraction from that, but that doesn’t 
make these concepts not worth learning. They’re recognition of problems 
too, not just solutions.

Matt

On Friday, February 2, 2018 at 9:35:42 PM UTC-6, as wrote:
>
> 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 
> composition, along with general interface use. I've recently seen a factory 
> in Go, it was rewritten into explicit declaration and this simplified the 
> code. The visitor "pattern" is just a function that gets called for a 
> traversed composite structure like a list or tree (see filepath.Walk). 
>
> 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
>>
>> 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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[as]

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 
composition, along with general interface use. I've recently seen a factory 
in Go, it was rewritten into explicit declaration and this simplified the 
code. The visitor "pattern" is just a function that gets called for a 
traversed composite structure like a list or tree (see filepath.Walk). 

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
>
> 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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.