Με ποια πρότυπα σχεδίασης είστε εξοικειωμένοι;

I am familiar with various design patterns used in Go. Some of the most common ones include:

Creational Patterns:

• Singleton: Ensures only one instance of a class exists and provides a global access point to it. In Go, it is often implemented using sync.Once.

  package main
  
  import (
  	"sync"
  )
  
  type singleton struct{}
  
  var instance *singleton
  var once sync.Once
  
  func GetInstance() *singleton {
  	once.Do(func() {
  		instance = &singleton{}
  	})
  	return instance
  }
  

• Factory Method: Defines an interface for creating an object, but allows subclasses to decide which class to instantiate. In Go, it is often implemented using functions that return interfaces.

  package main
  
  type Product interface {
  	Operate()
  }
  
  type ConcreteProductA struct{}
  
  func (p *ConcreteProductA) Operate() {
  	// Implementation of operation
  }
  
  type ConcreteProductB struct{}
  
  func (p *ConcreteProductB) Operate() {
  	// Implementation of operation
  }
  
  func NewProduct(productType string) Product {
  	switch productType {
  	case "A":
  		return &ConcreteProductA{}
  	case "B":
  		return &ConcreteProductB{}
  	default:
  		return nil // or error
  	}
  }
  

• Abstract Factory: Provides an interface for creating families of related or dependent objects without specifying their concrete classes.
• Builder: Separates the construction process of a complex object from its representation.

Structural Patterns:

• Adapter: Converts the interface of one class into another, required by clients. Allows classes to work together that otherwise would be incompatible.
• Decorator: Dynamically adds responsibilities to an object. Decorators provide a flexible alternative to inheritance for extending functionality.
• Facade: Provides a unified interface to a set of interfaces in a subsystem. Defines a high-level interface that makes the subsystem easier to use.
• Proxy: Acts as a substitute or placeholder for another object to control access to it.

Behavioral Patterns:

• Observer: Defines a one-to-many dependency between objects. When one object changes its state, all its dependents are notified and updated automatically.
• Strategy: Defines a family of algorithms, encapsulates each one, and makes them interchangeable. Allows algorithms to vary independently from clients that use them.

  package main
  
  type Strategy interface {
  	Execute(data string)
  }
  
  type ConcreteStrategyA struct{}
  
  func (s *ConcreteStrategyA) Execute(data string) {
  	// Implementation of Strategy A
  }
  
  type ConcreteStrategyB struct{}
  
  func (s *ConcreteStrategyB) Execute(data string) {
  	// Implementation of Strategy B
  }
  
  type Context struct {
  	strategy Strategy
  }
  
  func (c *Context) SetStrategy(strategy Strategy) {
  	c.strategy = strategy
  }
  
  func (c *Context) ExecuteStrategy(data string) {
  	c.strategy.Execute(data)
  }
  

• Template Method: Defines the skeleton of an algorithm in an operation, deferring some steps to subclasses. Allows subclasses to redefine certain steps of an algorithm without changing its structure.

In addition, I am familiar with patterns such as Command, Chain of Responsibility, Iterator, Mediator, Memento, State, Visitor. Go also frequently uses language-specific idioms, such as the use of interfaces for abstraction, goroutines, and channels for concurrency.