Design patterns in go (decorator, factory, composite, bridge, etc.)

<p>I came across this series of blogposts by <a href="http://blog.ralch.com/">Svetlin Ralchev</a> illustrating various design patterns implemented in Go and found it very helpful. Thought you all might enjoy it, too.</p> <ul> <li><a href="http://blog.ralch.com/tutorial/design-patterns/golang-decorator/">Decorator</a></li> <li><a href="http://blog.ralch.com/tutorial/design-patterns/golang-composite/">Composite</a></li> <li><a href="http://blog.ralch.com/tutorial/design-patterns/golang-bridge/">Bridge</a></li> <li><a href="http://blog.ralch.com/tutorial/design-patterns/golang-adapter/">Adapter</a></li> <li><a href="http://blog.ralch.com/tutorial/design-patterns/golang-prototype/">Prototype</a></li> <li><a href="http://blog.ralch.com/tutorial/design-patterns/golang-factory-method/">Factory Method</a></li> <li><a href="http://blog.ralch.com/tutorial/design-patterns/golang-builder/">Builder</a></li> <li><a href="http://blog.ralch.com/tutorial/design-patterns/golang-singleton/">Singleton</a></li> </ul> <hr/>**评论：**<br/><br/>jerf: <pre><p>I recall seeing another attempt to port design patterns into Go that was far, far worse than this. However, this still suffers from what I would consider to be excessively slavish dedication to the original format of the design patterns. The original design patterns book was written for C++, and even then was somewhat poorly ported into Scheme, a language that has rather different design patterns. In my opinion, you&#39;re much better off describing just the problem, skipping the original diagram entirely which is overcomplicated for Go (and almost every other language that isn&#39;t C++ or Java, honestly), and then showing the solution, rather than trying to match the diagram.</p> <p>For instance, in the Factory Method, all of the factories are attached to <code>type WhateverFactory struct {}</code> types, when they should just be functions. If you need a function that takes some input and decides what shape to return dynamically, you don&#39;t need the complicated machinery in the official Design Pattern, you need <code>type Shape interface { ... }</code> and <code>CreateShape(arguments...) Shape</code>.</p> <p>The decorator pattern as described is correct, but the description is greatly overcomplicated by the attempt to fit it into the structure of the design patterns of a different language; since Go basically natively implements decoration it&#39;s just a way of declaring <code>type Something interface {}</code> and making it so that a <code>type Decoration struct { inner Something }</code> provides an overriding implementation of whatever the Something interface does. (Or possibly <code>type Decoration struct { Something }</code>, depending.)</p> <p>And I&#39;m going to say it a second way to be clear; my objection is <em>not</em> to the general idea of documenting useful Go design patterns. It is certainly a language that has design patterns. My objection is using diagrams and concepts used for C++ and trying to jam them into Go, rather than simply discussing the problem and then the Go-native solutions. You will also miss out on design patterns specific to Go, such as ways you can use channels. Even if you&#39;re trying to educate someone very versed in the C++ design patterns in question, you&#39;re still better off going straight to problem and Go-native solution.</p></pre>gruey: <pre><p>This is basically describes a problem I see fairly often in practice: people impliment a design pattern and lose sight of the problem they are solving. You often end up with an overcomplicated, hard to understand mess instead of an elegant solution designed for maintainability.</p></pre>schumacherfm: <pre><p>This is then called &#34;Enterprise Software&#34; ;-(</p></pre>geodel: <pre><p>For my purpose Enterprise software like Spring provides endless supply of lovely class/method/variable names. </p></pre>