tmrts / go-patterns Goto Github PK

Instead of a list, using channels and select as demonstrated here makes for a much more beautiful demonstration.

.. I just noticed that a lot of pr's ans issues are open and that the last commit is very old?

The count function for loop should have <=. Currently it prints one less than expected.

http://tmrts.com/go-patterns/creational/abstract_factory.md

https://github.com/tmrts/go-patterns/blob/master/creational/abstract_factory.md

Clicking on a pattern which is unfinished (i.e status = ✘) provides no feedback on the website, nothing happens.

Clicking on the link multiple times appends the category to the URL multiple times. For example clicking on Abstract Factory three times yields the following url:

http://tmrts.com/go-patterns/creational/creational/creational/abstract_factory.md

Lastly, clicking on such an object twice makes all the other links (with status ✔) not work.

There are parts that you show in how to use the pattern that aren't in the example of creating it.

i.e. NewBuilder(), Paint(..), etc...

Hi! I saw that a some patterns have a link to related implementation (e.g. http://tmrts.com/go-patterns/stability/circuit-breaker.html). Can I add via pull request some implementation of synchronization/semaphore?

• https://github.com/eapache/go-resiliency/blob/master/semaphore/semaphore.go
• https://github.com/dropbox/godropbox/blob/master/sync2/semaphore.go
• https://github.com/kamilsk/semaphore

Factory Method Pattern in Go is function which returns an interface (something what is implementing an interface)... that's all. This means you should not think about this pattern and use a pattern when you known patterns. You should make only a function like func NewXXX(arguments) <interface> {...} for your needs (or in ideal case package.New()). And every gofer are making this everyday. And it is not a pattern. This is Interface builder or Interface constructor as you like.
I affirm that Go does not require knowledge of any patterns (as OOP requires), but it requires an understanding of SOLID principles and having a mind.

The circuit breaker example is mostly a copy paste from sony/gobreaker/gobreaker.go without credit for the original authors. Furthermore, the example doesn't build due to missing constants: Counts and State.

can't open https://github.com/tmrts/go-patterns/blob/master/concurrency/broadcast.md

https://github.com/tmrts/go-patterns/blob/master/README.md -> All links redirects to github 404 page not found.

the use of channels to control the pool is fine, but IMHO it's much better to use the sync.Pool from the stdlib

Should one do a go get or should one copy and modify the code in the personal projects

Hi! There are some other pattern creators, where they or you can find some inspiration.
Here is a link to ine of them: https://github.com/AlexanderGrom/go-patterns/tree/master/Behavioral

There are patterns like Memento & Mediator, that you didn't have here, and many others. Are they bad, outdated or you just try create your own implementations?

https://github.com/tmrts/go-patterns/blob/master/messaging/publish_subscribe.md

 if _, ok := s.ch; !ok {
        return errors.New("Topic has been closed")
 }

assignment count mismatch: 2 = 1

https://github.com/tmrts/go-patterns/blob/master/README.md -> All links redirects to github 404 page not found.

The singleton code does not run

singleton\singleton.go:6: undefined: sync in sync.Once

unless

import "sync"

is added

Recent CI build failed due to npm incompatibility - see https://stackoverflow.com/questions/45049768/gitbook-cli-install-error-gitbook-cli-v-cannot-be-use

Currently, the recommended way according to https://github.com/GitbookIO/gitbook-cli is to
npm install -g gitbook-cli

decorator pattern is very perfunctory，i Can't understand why this project has so many stars

It would be very useful if someone could provide reference to some patterns that are being used in go language library or some established(well known) go projects.

That will give an idea how these patterns are being used in real life.

If you want to develop great software, do not use anything in here. It's a good way to create an unmaintainable, unreadable and a frustrating codebase that no one can figure out. Take a look at the Golang standard library, do you see anything about a Factory, Flywheel, or any other non-sense design pattern? Nope.

Stay far away from these patterns in Golang and never use these patterns unless you have a decade of experience and have successfully shipped and maintained a codebase for at least 3 years.

This repository should have a big warning saying "STAY AWAY UNLESS YOU ARE ROB PIKE"

The README mentions a composite pattern:

/structural/composite.md

but no such file exsists.

thanks.

I think in the functional-option.md in the Constructor section, the type of the New() function returned values ​​is different from the type required in the function signature.
Related link

first of all , i 'm very glad to help to stay still in current repo ,if with author's permission.

currently , I did some digging ,found some guys made great progressing basing on current projects ,but which also looks staled ,so i did the the following actions :

i created a following fork https://github.com/crazybber/awesome-patterns, with many awesome forks merged. such as:

Merged : https://github.com/nynicg/go-patterns
Merged : https://github.com/weichou1229/go-patterns
Merged : https://github.com/jianhan/go-patterns
Merged : https://github.com/sakari-ai/go-patterns
Merged ：https://github.com/restudy/go-patterns
.....

maybe, your guys will be interesting.
maybe, we can make this repo great again .

if you have some or similar idea ,come her : go-patterns.

An example of the flyweight pattern in Golang is given here: http://www.hydrogen18.com/blog/golang-embedding.html

https://github.com/tmrts/go-patterns/blob/4f4ceb2dc1b4b9b5bb2985da4599fbc1aa4bddd2/parallelism/md5.go

Hi, I'm Yevgeny Pats Founder of Fuzzit - Continuous fuzzing as a service platform.

We have a free plan for OSS and I would be happy to contribute a PR if that's interesting.
The PR will include the following

• go-fuzz fuzzers (This is generic step not-connected to fuzzit)
• Continuous Fuzzing of master branch which will generate new corpus and look for new crashes
• Regression on every PR that will run the fuzzers through all the generated corpus and fixed crashes from previous step. This will prevent new or old bugs from crippling into master.

You can see our basic example here and you can see an example of "in the wild" integration here.

Let me know if this is something worth working on.

Cheers,
Yevgeny