what is the difference between pool and prototype patterns?

I've just read the chapter on Creational patterns in the book Design Patterns in golang. These are:

• factory
• abstract factory
• prototype
• singleton
• builder

I've created a repository on github to list all of them. I've looked for other repositories like mine:

• tmrts/go-patterns
• yksz/go-design-patterns
• jeanphorn/go-design-patterns

Some list object-pool as a pattern, others simple-factory and factory-method. Does there exist an official list of creational patterns in go? Is it important to know the list, or is it more important to know what is possible and be able to use right code in right context? With or without know all the patterns in the world?

And, ... what is the difference between prototype and object pool patterns? They look very similar to me.

A Pool helps limit the number of new objects allocated; a Prototype is a way of specifying how a new object is created.

Object pools are concerned with caching created instances of objects that can be accessed later. Golang has an implementation (https://golang.org/pkg/sync/#Pool) which is mainly used for relieving pressure on the garbage collector. The usual way of using a pool follows something like:

1. ask the pool for an instance
2. The pool will either give you back an unused object, or it will allocate a new object, and give the new instance back to you
3. You use the object to do whatever you need
4. You give the object back to the pool so that another "client" can use it.

In the Pool implementation, you'll notice that you can pass a "creation" function to specify how the pool should create an instance in Step 2.

New func() interface{}

This function could simply allocate an empty struct, or it could use a Prototype pattern to clone new instances if the creation logic was complicated.

The Prototype pattern is more focused on abstracting how you can create many "copies" of an object from a prototype object. You mainly use this pattern when you want to try and avoid the use of the new keyword.

Design Patterns do not exist in isolation, they have relationships of their own. So for example, an object pool might use a factory or prototype to initially fill the pool or deal with exhaustion. The objects in that pool might conform to the command pattern, or be examples of the builder pattern.

In practice you cannot possibly know all the details of all patterns, the most important thing to know is the intent. What the pattern achieves. When using the pattern the remaining details can and should be taken from a pattern catalogue, over time you will learn some patterns comprehensively and reference others.

A Pattern Catalogue is the a collection of fully documented Design Patterns. The GoF Design Patterns book is probably the most famous Pattern Catalogue, however the book you mention and even github repositories can fulfil the same purpose.