go

Introduction The Bridge Pattern is a creational design pattern used to decouple an abstraction from its implementation. The bridge uses encapsulation, aggregation, and can use inheritance to separate responsibilities into different classes. Purpose Decouple an abstraction from its implementation that allows both to vary independently. Publish interface in an inheritance hierarchy, and bury implementation in its own inheritance hierarchy. Design Pattern Diagram The objects participating in this pattern are presented on the following diagram:...

Go does not have an Exception handling model as most of the main stream languages. However, it uses the error interface type as the return type for any error that is going to be returned from a function or method: type error interface { Error() string } It is an interface type. An error variable represents any value that can describe itself as a string. The most commonly-used error implementation is in the errors package....

Introduction The Adapter Pattern is responsible for adaptation of two incompatible interfaces. It is a structural pattern that is responsible to join functionalities of independent or incompatible interfaces without modifing their implementation. Interfaces may be incompatible but the inner functionality should suit the need. It allows otherwise incompatible objects to work together by converting the interface of each struct into an interface expected by the clients. Purpose Impedance match an old component to a new system Wrap the interface of a object into another interface clients expect....

Preface The Prototype Pattern creates duplicate objects while keeping performance in mind. It’s a part of the creational patterns and provides one of the best ways to create an object. In the mainstream languages (like C# and JAVA), it requires implementing a prototype interface which tells to create a clone of the current object. It is used when creation of object directly is costly. For instance, an object is to be created after a costly database operation....

Recently I started a series of articles about Gang of Four Design Patterns and their adoption in Golang. They made a lot of noise in the community. I read a lot of contradictionary opionions whether should be used or not. I am publishing those articles as show case how the common design patterns can be adopted and implemented in Golang. I don’t encourage or promote their usage. Every developer has own style of programming, architecture desing and problem solving solutions....