Creational patterns
Creational design patterns provide various object creation mechanisms, which increase flexibility and reuse of existing code.
Factory Method
separates product construction code from the code that actually uses the product
Note that the factory method doesn’t have to create new instances all the time. It can also return existing objects from a cache, an object pool, or another source.
Applicability
Use the Factory Method when you don’t know beforehand the exact types and dependencies of the objects your code should work with.
Use the Factory Method when you want to provide users of your library or framework with a way to extend its internal components.
abstract factory
to various families of related products
Builder
Builder is a creational design pattern that lets you construct complex objects step by step.
There’s another approach that doesn’t involve breeding subclasses. You can create a giant constructor right in the base House class with all possible parameters that control the house object. While this approach indeed eliminates the need for subclasses, it creates another problem.
Prototype
The Prototype pattern delegates the cloning process to the actual objects that are being cloned.
say you have an object, and you want to create an exact copy of it. How would you do it? First, you have to create a new object of the same class. Then you have to go through all the fields of the original object and copy their values over to the new object.
Nice! But there’s a catch. Not all objects can be copied that way because some of the object’s fields may be private and not visible from outside of the object itself.
Singleton
Singleton is a creational design pattern that lets you ensure that a class has only one instance, while providing a global access point to this instance.
Applicability
** Use the Singleton pattern when a class in your program should have just a single instance available to all clients; for example, a single database object shared by different parts of the program.
Use the Singleton pattern when you need stricter control over global variables.
**
package main
import (
"fmt"
"sync"
)
var lock = &sync.Mutex{}
type single struct {
}
var singleInstance *single
func getInstance() *single {
if singleInstance == nil {//第一次校验是为了代码提高代码执行效率,创建了一个实例之后,直接返回前面创建的实例即可,不必要进入同步代码块去竞争锁
lock.Lock()
defer lock.Unlock()
if singleInstance == nil {//防止重复创建实例
fmt.Println("Creating single instance now.")
singleInstance = &single{}
} else {
fmt.Println("Single instance already created.")
}
} else {
fmt.Println("Single instance already created.")
}
return singleInstance
}
// General singleton class.
class Singleton {
// Hold the class instance.
private static $instance = null;
// The constructor is private
// to prevent initiation with outer code.
private function __construct()
{
// The expensive process (e.g.,db connection) goes here.
}
// The object is created from within the class itself
// only if the class has no instance.
public static function getInstance()
{
if (self::$instance == null)
{
self::$instance = new Singleton();
}
return self::$instance;
}
}