diff --git a/.gitignore b/.gitignore
index f72f0cd..daf913b 100644
--- a/.gitignore
+++ b/.gitignore
@@ -19,16 +19,6 @@ _cgo_export.*
_testmain.go
-*.prof
-# Test binary, build with `go test -c`
-*.test
-# Binaries for programs and plugins
*.exe
-*.dll
-*.dylib
-
-# JetBrains project files
-.idea/
-
-# Output of the go coverage tool, specifically when used with LiteIDE
-*.out
\ No newline at end of file
+*.test
+*.prof
diff --git a/CONTRIBUTING.html b/CONTRIBUTING.html
new file mode 100644
index 0000000..e94dc67
--- /dev/null
+++ b/CONTRIBUTING.html
@@ -0,0 +1,1047 @@
+
+
+
+
Please ensure your pull request adheres to the following guidelines:
+
+
Make an individual pull request for each suggestion.
+
Choose the corresponding patterns section for your suggestion.
+
List, after your addition, should be in lexicographical order.
+
+
Commit Messages Guidelines
+
+
The message should be in imperative form and uncapitalized.
+
If possible, please include an explanation in the commit message body
+
Use the form <pattern-section>/<pattern-name>: <message> (e.g. creational/singleton: refactor singleton constructor)
+
+
Pattern Template
+
Each pattern should have a single markdown file containing the important part of the implementation, the usage and the explanations for it. This is to ensure that the reader doesn't have to read bunch of boilerplate to understand what's going on and the code is as simple as possible and not simpler.
+
Please use the following template for adding new patterns:
+
# <Pattern-Name>
+<Patterndescription>
+
+## Implementation
+
+## Usage
+
+// Optional
+## Rules of Thumb
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
deleted file mode 100644
index 7ae7acb..0000000
--- a/CONTRIBUTING.md
+++ /dev/null
@@ -1,31 +0,0 @@
-# Contribution Guidelines
-
-Please ensure your pull request adheres to the following guidelines:
-
-- Make an individual pull request for each suggestion.
-- Choose the corresponding patterns section for your suggestion.
-- List, after your addition, should be in lexicographical order.
-
-## Commit Messages Guidelines
-
-- The message should be in imperative form and uncapitalized.
-- If possible, please include an explanation in the commit message body
-- Use the form `/: ` (e.g. `creational/singleton: refactor singleton constructor`)
-
-## Pattern Template
-
-Each pattern should have a single markdown file containing the important part of the implementation, the usage and the explanations for it. This is to ensure that the reader doesn't have to read bunch of boilerplate to understand what's going on and the code is as simple as possible and not simpler.
-
-Please use the following template for adding new patterns:
-
-```markdown
-#
-
-
-## Implementation
-
-## Usage
-
-// Optional
-## Rules of Thumb
-```
diff --git a/README.md b/README.md
deleted file mode 100644
index 7d9f5f7..0000000
--- a/README.md
+++ /dev/null
@@ -1,110 +0,0 @@
-
-
-
- Go Patterns
-
-
-
-
-
-
-
-A curated collection of idiomatic design & application patterns for Go language.
-
-## Creational Patterns
-
-| Pattern | Description | Status |
-|:-------:|:----------- |:------:|
-| [Abstract Factory](/creational/abstract_factory.md) | Provides an interface for creating families of releated objects | ✘ |
-| [Builder](/creational/builder.md) | Builds a complex object using simple objects | ✔ |
-| [Factory Method](/creational/factory.md) | Defers instantiation of an object to a specialized function for creating instances | ✔ |
-| [Object Pool](/creational/object-pool.md) | Instantiates and maintains a group of objects instances of the same type | ✔ |
-| [Singleton](/creational/singleton.md) | Restricts instantiation of a type to one object | ✔ |
-
-## Structural Patterns
-
-| Pattern | Description | Status |
-|:-------:|:----------- |:------:|
-| [Bridge](/structural/bridge.md) | Decouples an interface from its implementation so that the two can vary independently | ✘ |
-| [Composite](/structural/composite.md) | Encapsulates and provides access to a number of different objects | ✘ |
-| [Decorator](/structural/decorator.md) | Adds behavior to an object, statically or dynamically | ✔ |
-| [Facade](/structural/facade.md) | Uses one type as an API to a number of others | ✘ |
-| [Flyweight](/structural/flyweight.md) | Reuses existing instances of objects with similar/identical state to minimize resource usage | ✘ |
-| [Proxy](/structural/proxy.md) | Provides a surrogate for an object to control it's actions | ✔ |
-
-## Behavioral Patterns
-
-| Pattern | Description | Status |
-|:-------:|:----------- |:------:|
-| [Chain of Responsibility](/behavioral/chain_of_responsibility.md) | Avoids coupling a sender to receiver by giving more than object a chance to handle the request | ✘ |
-| [Command](/behavioral/command.md) | Bundles a command and arguments to call later | ✘ |
-| [Mediator](/behavioral/mediator.md) | Connects objects and acts as a proxy | ✘ |
-| [Memento](/behavioral/memento.md) | Generate an opaque token that can be used to go back to a previous state | ✘ |
-| [Observer](/behavioral/observer.md) | Provide a callback for notification of events/changes to data | ✔ |
-| [Registry](/behavioral/registry.md) | Keep track of all subclasses of a given class | ✘ |
-| [State](/behavioral/state.md) | Encapsulates varying behavior for the same object based on its internal state | ✘ |
-| [Strategy](/behavioral/strategy.md) | Enables an algorithm's behavior to be selected at runtime | ✔ |
-| [Template](/behavioral/template.md) | Defines a skeleton class which defers some methods to subclasses | ✘ |
-| [Visitor](/behavioral/visitor.md) | Separates an algorithm from an object on which it operates | ✘ |
-
-## Synchronization Patterns
-
-| Pattern | Description | Status |
-|:-------:|:----------- |:------:|
-| [Condition Variable](/synchronization/condition_variable.md) | Provides a mechanism for threads to temporarily give up access in order to wait for some condition | ✘ |
-| [Lock/Mutex](/synchronization/mutex.md) | Enforces mutual exclusion limit on a resource to gain exclusive access | ✘ |
-| [Monitor](/synchronization/monitor.md) | Combination of mutex and condition variable patterns | ✘ |
-| [Read-Write Lock](/synchronization/read_write_lock.md) | Allows parallel read access, but only exclusive access on write operations to a resource | ✘ |
-| [Semaphore](/synchronization/semaphore.md) | Allows controlling access to a common resource | ✔ |
-
-## Concurrency Patterns
-
-| Pattern | Description | Status |
-|:-------:|:----------- |:------:|
-| [N-Barrier](/concurrency/barrier.md) | Prevents a process from proceeding until all N processes reach to the barrier | ✘ |
-| [Bounded Parallelism](/concurrency/bounded_parallelism.md) | Completes large number of independent tasks with resource limits | ✔ |
-| [Broadcast](/concurrency/broadcast.md) | Transfers a message to all recipients simultaneously | ✘ |
-| [Coroutines](/concurrency/coroutine.md) | Subroutines that allow suspending and resuming execution at certain locations | ✘ |
-| [Generators](/concurrency/generator.md) | Yields a sequence of values one at a time | ✔ |
-| [Reactor](/concurrency/reactor.md) | Demultiplexes service requests delivered concurrently to a service handler and dispatches them syncronously to the associated request handlers | ✘ |
-| [Parallelism](/concurrency/parallelism.md) | Completes large number of independent tasks | ✔ |
-| [Producer Consumer](/concurrency/producer_consumer.md) | Separates tasks from task executions | ✘ |
-
-## Messaging Patterns
-
-| Pattern | Description | Status |
-|:-------:|:----------- |:------:|
-| [Fan-In](/messaging/fan_in.md) | Funnels tasks to a work sink (e.g. server) | ✔ |
-| [Fan-Out](/messaging/fan_out.md) | Distributes tasks among workers (e.g. producer) | ✔ |
-| [Futures & Promises](/messaging/futures_promises.md) | Acts as a place-holder of a result that is initially unknown for synchronization purposes | ✘ |
-| [Publish/Subscribe](/messaging/publish_subscribe.md) | Passes information to a collection of recipients who subscribed to a topic | ✔ |
-| [Push & Pull](/messaging/push_pull.md) | Distributes messages to multiple workers, arranged in a pipeline | ✘ |
-
-## Stability Patterns
-
-| Pattern | Description | Status |
-|:-------:|:----------- |:------:|
-| [Bulkheads](/stability/bulkhead.md) | Enforces a principle of failure containment (i.e. prevents cascading failures) | ✘ |
-| [Circuit-Breaker](/stability/circuit-breaker.md) | Stops the flow of the requests when requests are likely to fail | ✔ |
-| [Deadline](/stability/deadline.md) | Allows clients to stop waiting for a response once the probability of response becomes low (e.g. after waiting 10 seconds for a page refresh) | ✘ |
-| [Fail-Fast](/stability/fail_fast.md) | Checks the availability of required resources at the start of a request and fails if the requirements are not satisfied | ✘ |
-| [Handshaking](/stability/handshaking.md) | Asks a component if it can take any more load, if it can't, the request is declined | ✘ |
-| [Steady-State](/stability/steady_state.md) | For every service that accumulates a resource, some other service must recycle that resource | ✘ |
-
-## Profiling Patterns
-
-| Pattern | Description | Status |
-|:-------:|:----------- |:------:|
-| [Timing Functions](/profiling/timing.md) | Wraps a function and logs the execution | ✔ |
-
-## Idioms
-
-| Pattern | Description | Status |
-|:-------:|:----------- |:------:|
-| [Functional Options](/idiom/functional-options.md) | Allows creating clean APIs with sane defaults and idiomatic overrides | ✔ |
-
-## Anti-Patterns
-
-| Pattern | Description | Status |
-|:-------:|:----------- |:------:|
-| [Cascading Failures](/anti-patterns/cascading_failures.md) | A failure in a system of interconnected parts in which the failure of a part causes a domino effect | ✘ |
diff --git a/SUMMARY.md b/SUMMARY.md
deleted file mode 100644
index 9337c64..0000000
--- a/SUMMARY.md
+++ /dev/null
@@ -1,62 +0,0 @@
-# Summary
-
-* [Go Patterns](/README.md)
- * [Creational Patterns](/README.md#creational-patterns)
- * [Abstract Factory](/creational/abstract_factory.md)
- * [Builder](/creational/builder.md)
- * [Factory Method](/creational/factory.md)
- * [Object Pool](/creational/object-pool.md)
- * [Singleton](/creational/singleton.md)
- * [Structural Patterns](/README.md#structural-patterns)
- * [Bridge](/structural/bridge.md)
- * [Composite](/structural/composite.md)
- * [Decorator](/structural/decorator.md)
- * [Facade](/structural/facade.md)
- * [Flyweight](/structural/flyweight.md)
- * [Proxy](/structural/proxy.md)
- * [Behavioral Patterns](/README.md#behavioral-patterns)
- * [Chain of Responsibility](/behavioral/chain_of_responsibility.md)
- * [Command](/behavioral/command.md)
- * [Mediator](/behavioral/mediator.md)
- * [Memento](/behavioral/memento.md)
- * [Observer](/behavioral/observer.md)
- * [Registry](/behavioral/registry.md)
- * [State](/behavioral/state.md)
- * [Strategy](/behavioral/strategy.md)
- * [Template](/behavioral/template.md)
- * [Visitor](/behavioral/visitor.md)
- * [Synchronization Patterns](/README.md#synchronization-patterns)
- * [Condition Variable](/synchronization/condition_variable.md)
- * [Lock/Mutex](/synchronization/mutex.md)
- * [Monitor](/synchronization/monitor.md)
- * [Read-Write Lock](/synchronization/read_write_lock.md)
- * [Semaphore](/synchronization/semaphore.md)
- * [Concurrency Patterns](/README.md#concurrency-patterns)
- * [N-Barrier](/concurrency/barrier.md)
- * [Bounded Parallelism](/concurrency/bounded_parallelism.md)
- * [Broadcast](/concurrency/broadcast.md)
- * [Coroutines](/concurrency/coroutine.md)
- * [Generators](/concurrency/generator.md)
- * [Reactor](/concurrency/reactor.md)
- * [Parallelism](/concurrency/parallelism.md)
- * [Producer Consumer](/concurrency/producer_consumer.md)
- * [Messaging Patterns](/README.md#messaging-patterns)
- * [Fan-In](/messaging/fan_in.md)
- * [Fan-Out](/messaging/fan_out.md)
- * [Futures & Promises](/messaging/futures_promises.md)
- * [Publish/Subscribe](/messaging/publish_subscribe.md)
- * [Push & Pull](/messaging/push_pull.md)
- * [Stability Patterns](/README.md#stability-patterns)
- * [Bulkheads](/stability/bulkhead.md)
- * [Circuit-Breaker](/stability/circuit-breaker.md)
- * [Deadline](/stability/deadline.md)
- * [Fail-Fast](/stability/fail_fast.md)
- * [Handshaking](/stability/handshaking.md)
- * [Steady-State](/stability/steady_state.md)
- * [Profiling Patterns](/README.md#profiling-patterns)
- * [Timing Functions](/profiling/timing.md)
- * [Idioms](/README.md#idioms)
- * [Functional Options](/idiom/functional-options.md)
- * [Anti-Patterns](/README.md#anti-patterns)
- * [Cascading Failures](/anti-patterns/cascading_failures.md)
-* [Contributing](/CONTRIBUTING.md)
diff --git a/behavioral/observer.html b/behavioral/observer.html
new file mode 100644
index 0000000..8b42fdb
--- /dev/null
+++ b/behavioral/observer.html
@@ -0,0 +1,1066 @@
+
+
+
+
+
+
+ Observer · GitBook
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
The observer pattern allows a type instance to "publish" events to other type instances ("observers") who wish to be updated when a particular event occurs.
+
Implementation
+
In long-running applications—such as webservers—instances can keep a collection of observers that will receive notification of triggered events.
+
Implementations vary, but interfaces can be used to make standard observers and notifiers:
+
type (
+ // Event defines an indication of a point-in-time occurrence.
+ Event struct {
+ // Data in this case is a simple int, but the actual
+ // implementation would depend on the application.
+ Data int64
+ }
+
+ // Observer defines a standard interface for instances that wish to list for
+ // the occurrence of a specific event.
+ Observer interface {
+ // OnNotify allows an event to be "published" to interface implementations.
+ // In the "real world", error handling would likely be implemented.
+ OnNotify(Event)
+ }
+
+ // Notifier is the instance being observed. Publisher is perhaps another decent
+ // name, but naming things is hard.
+ Notifier interface {
+ // Register allows an instance to register itself to listen/observe
+ // events.
+ Register(Observer)
+ // Deregister allows an instance to remove itself from the collection
+ // of observers/listeners.
+ Deregister(Observer)
+ // Notify publishes new events to listeners. The method is not
+ // absolutely necessary, as each implementation could define this itself
+ // without losing functionality.
+ Notify(Event)
+ }
+)
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/behavioral/observer.md b/behavioral/observer.md
deleted file mode 100644
index c48de84..0000000
--- a/behavioral/observer.md
+++ /dev/null
@@ -1,47 +0,0 @@
-# Observer Pattern
-
-The [observer pattern](https://en.wikipedia.org/wiki/Observer_pattern) allows a type instance to "publish" events to other type instances ("observers") who wish to be updated when a particular event occurs.
-
-## Implementation
-
-In long-running applications—such as webservers—instances can keep a collection of observers that will receive notification of triggered events.
-
-Implementations vary, but interfaces can be used to make standard observers and notifiers:
-
-```go
-type (
- // Event defines an indication of a point-in-time occurrence.
- Event struct {
- // Data in this case is a simple int, but the actual
- // implementation would depend on the application.
- Data int64
- }
-
- // Observer defines a standard interface for instances that wish to list for
- // the occurrence of a specific event.
- Observer interface {
- // OnNotify allows an event to be "published" to interface implementations.
- // In the "real world", error handling would likely be implemented.
- OnNotify(Event)
- }
-
- // Notifier is the instance being observed. Publisher is perhaps another decent
- // name, but naming things is hard.
- Notifier interface {
- // Register allows an instance to register itself to listen/observe
- // events.
- Register(Observer)
- // Deregister allows an instance to remove itself from the collection
- // of observers/listeners.
- Deregister(Observer)
- // Notify publishes new events to listeners. The method is not
- // absolutely necessary, as each implementation could define this itself
- // without losing functionality.
- Notify(Event)
- }
-)
-```
-
-## Usage
-
-For usage, see [observer/main.go](observer/main.go) or [view in the Playground](https://play.golang.org/p/cr8jEmDmw0).
diff --git a/behavioral/strategy.html b/behavioral/strategy.html
new file mode 100644
index 0000000..f7f9404
--- /dev/null
+++ b/behavioral/strategy.html
@@ -0,0 +1,1071 @@
+
+
+
+
+
+
+ Strategy · GitBook
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
Generators) yields a sequence of values one at a time.
+
Implementation
+
func Count(start int, end int) chanint {
+ ch := make(chanint)
+
+ gofunc(ch chanint) {
+ for i := start; i <= end ; i++ {
+ // Blocks on the operation
+ ch <- i
+ }
+
+ close(ch)
+ }(ch)
+
+ return ch
+}
+
+
Usage
+
fmt.Println("No bottles of beer on the wall")
+
+for i := range Count(1, 99) {
+ fmt.Println("Pass it around, put one up,", i, "bottles of beer on the wall")
+ // Pass it around, put one up, 1 bottles of beer on the wall
+ // Pass it around, put one up, 2 bottles of beer on the wall
+ // ...
+ // Pass it around, put one up, 99 bottles of beer on the wall
+}
+
+fmt.Println(100, "bottles of beer on the wall")
+
Builder pattern separates the construction of a complex object from its
+representation so that the same construction process can create different
+representations.
+
In Go, normally a configuration struct is used to achieve the same behavior,
+however passing a struct to the builder method fills the code with boilerplate
+if cfg.Field != nil {...} checks.
The object pool creational design pattern is used to prepare and keep multiple
+instances according to the demand expectation.
+
Implementation
+
package pool
+
+type Pool chan *Object
+
+func New(total int) *Pool {
+ p := make(Pool, total)
+
+ for i := 0; i < total; i++ {
+ p <- new(Object)
+ }
+
+ return &p
+}
+
+
Usage
+
Given below is a simple lifecycle example on an object pool.
+
p := pool.New(2)
+
+select {
+case obj := <-p:
+ obj.Do( /*...*/ )
+
+ p <- obj
+default:
+ // No more objects left — retry later or fail
+ return
+}
+
+
Rules of Thumb
+
+
Object pool pattern is useful in cases where object initialization is more
+expensive than the object maintenance.
+
If there are spikes in demand as opposed to a steady demand, the maintenance
+overhead might overweigh the benefits of an object pool.
+
It has positive effects on performance due to objects being initialized beforehand.