04_对象创建模式

最新推荐文章于 2024-07-18 22:51:23 发布
最新推荐文章于 2024-07-18 22:51:23 发布
阅读量116 收藏
点赞数
分类专栏： 设计模式 文章标签： golang 设计模式
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/u013671216/article/details/131572764
版权

对象创建模式

通过“对象创建” 模式绕开new，来避免对象创建（new）过程中所导致的紧耦合（依赖具体类），从而支持对象创建的稳定。它是接口抽象之后的第一步工作。

典型模式：

  • Factory Method
  • Abstract Factory
  • Prototype
  • Builder

Factory Method工厂方法

定义一个用于创建对象的接口，让子类决定实例化哪一个类。Factory Method使得一个类的实例化延迟（目的：解耦，手段：虚函数）到子类。

动机：

  • 在软件系统中，经常面临着创建对象的工作；由于需求的变化，需要创建的对象的具体类型经常变化。
  • 如何应对这种变化？如何绕过常规的对象创建方法(new)，提供一种“封装机制”来避免客户程序和这种“具体对象创建工作”的紧耦合？

例子

同样以文件分割器为例，有一个较大的文件，想要被分成多个小块的文件。

package factory_method

import "strconv"

type FileSplitter struct {
	path string
	nums int
}

func (s *FileSplitter) split() {
	//do something
	//split a big file to nums small files
	for i := 0; i < s.nums; i++ {

	}
}

type TextBox struct {
	text string
}

func (box *TextBox) getText() string {
	return box.text
}

type MainForm struct {
	txtFilePath   *TextBox
	txtFileNumber *TextBox
}

func (main *MainForm) Button1_Click() {
	filePath := main.txtFilePath.getText()
	number, _ := strconv.Atoi(main.txtFileNumber.getText())
	splitter := FileSplitter{filePath, number}
	splitter.split()
}

当点击后就会执行分隔。

由于，FileSplitter可能是想要变化的，在button点击里被写死了，不能改变了。假设有BinarySplitter, TxtSplitter,PictureSplitter,VideoSplitter,这么多分割器，

首先想要抽象出一个分割器

// 分割器的抽象
type ISplitter interface {
	split()
}

具体实现


// 二进制文件分割器
type BinarySplitter struct {
	ISplitter //继承
}

func (bin *BinarySplitter) split() {
	fmt.Println("BinarySplitter split")
}

// Txt文件分割器
type TxtSplitter struct {
	ISplitter //继承
}

func (txt *TxtSplitter) split() {
	fmt.Println("TxtSplitter split")
}

// Picture分割器
type PictureSplitter struct {
	ISplitter //继承
}

func (pic *PictureSplitter) split() {
	fmt.Println("PictureSplitter split")
}

// Video分割器
type VideoSplitter struct {
	ISplitter //继承
}

func (video *VideoSplitter) split() {
	fmt.Println("VideoSplitter split")
}

然后我们可以将实例化改变,

func (main *MainForm) Button1_Click() {
	_ = main.txtFilePath.getText()
	_, _ = strconv.Atoi(main.txtFileNumber.getText())
	var splitter ISplitter
	splitter = &BinarySplitter{}
	splitter.split()
}

左边确实是抽象依赖了，但是BinarySplitter仍然是依赖具体，打破了依赖倒置原则。

于是如何去除BinarySplitter这样的具体依赖就是创建模式要解决的问题。这是面向接口编程的必然需求。

对象创建的方法，不用new

用一个方法来返回我们需要的对象。

// 分割工厂
type SplitterFactory struct {
}

func (sf *SplitterFactory) CreateSplitter() ISplitter {
	return &BinarySplitter{}
}

使用

func (main *MainForm) Button1_Click() {
	_ = main.txtFilePath.getText()
	_, _ = strconv.Atoi(main.txtFileNumber.getText())
	var splitter ISplitter
	var factory SplitterFactory
	splitter = factory.CreateSplitter()
	splitter.split()
}

但是实际上由于CreateSplitter（编译时）依赖于BinarySplitter，由于依赖的传递性，所以仍然没有解决问题。

考虑将具体实现交给后续调用，设计为接口

// 分割工厂
type SplitterFactory interface {
	CreateSplitter() ISplitter
}

func (main *MainForm) Button1_Click() {
	_ = main.txtFilePath.getText()
	_, _ = strconv.Atoi(main.txtFileNumber.getText())
	var splitter ISplitter
	var factory SplitterFactory
	splitter = factory.CreateSplitter()
	splitter.split()
}

那么SplitterFactory又赋值什么呢？

通过工厂创建具体的对象，

// 具体工厂
// 二进制文件分割器工厂
type BinarySplitterFactory struct {
	SplitterFactory //继承
}

func (bin *BinarySplitterFactory) CreateSplitter() ISplitter {
	return &BinarySplitter{}
}

// Txt文件分割器工厂
type TxtSplitterFactory struct {
	SplitterFactory //继承
}

func (txt *TxtSplitterFactory) CreateSplitter() ISplitter {
	return &TxtSplitter{}
}

// Picture分割器工厂
type PictureSplitterFactory struct {
	SplitterFactory //继承
}

func (pic *PictureSplitterFactory) CreateSplitter() ISplitter {
	return &PictureSplitter{}
}

// Video分割器工厂
type VideoSplitterFactory struct {
	SplitterFactory //继承
}

func (video *VideoSplitterFactory) CreateSplitter() ISplitter {
	return &VideoSplitter{}
}

那么SplitterFactory又什么时候赋值呢？

一般是构造具体的MainForm的时候

type MainForm struct {
	factory SplitterFactory
}

func NewMainForm(factory SplitterFactory) *MainForm {
	return &MainForm{factory: factory}
}

func (main *MainForm) Button1_Click() {
	splitter := main.factory.CreateSplitter()
	splitter.split()
}

这就实现了多态实例化的功能。

问题，将来实际上还是有具体的实现。

答：MainForm里不依赖了，具体不由我来实现了，而把这个变化放到其他对方去了。

使用

func TestMainForm_Button1_Click(t *testing.T) {
	//真正实例化的地方，
	main := NewMainForm(&PictureSplitterFactory{})
	main.Button1_Click()
}

类图
ISplitter
+split()
SplitterFactory
+CreateSplitter()
BinarySplitter
+split()
TxtSplitter
+split()
PictureSplitter
+split()
VideoSplitter
+split()
BinarySplitterFactory
+CreateSplitter()
TxtSplitterFactory
+CreateSplitter()
PictureSplitterFactory
+CreateSplitter()
VideoSplitterFactory
+CreateSplitter()
MainForm
- factory: SplitterFactory
+Button1_Click()

总结

书上类图：

在这里插入图片描述

总结：

  • Factory Method模式用于隔离类对象的使用者和具体类型之间的耦合关系。面对一个经常变化的具体类型，紧耦合关系(new)会导致软件的脆弱。
  • Factory Method模式通过面向对象的手法，将所要创建的具体对象工作延迟到子类，从而实现一种扩展（而非更改）的策略，较好地解决了这种紧耦合关系。
  • Factory Method模式解决“单个对象”的需求变化。缺点在于要求创建方法/参数相同。

抽象工厂

提供一个接口，让该接口负责创建一系列“相关或者相互依赖的对象”，无需指定它们具体的类。

动机

  • 在软件系统中，经常面临着“一系列相互依赖的对象”的创建工作；同时，由于需求的变化，往往存在更多系列对象的创建工作。
  • 如何应对这种变化？如何绕过常规的对象创建方法(new)，提供一种“封装机制”来避免客户程序和这种“多系列具体对象创建工作”的紧耦合？

对不同的数据库需要不同的实现，SqlConnection,SqlCommand,想法是先抽象

如果按照工厂方法，解决一个类对应一个工厂。一个具体实现一个具体工厂类。

package abstract_factory

// 数据库访问有关的接口
type IDBConnection interface {
}

// 工厂
type IDBConnectionFactory interface {
	CreateDBConnection() IDBConnection
}
type IDBCommand interface {
	SetConnection(connection IDBConnection)
}
type IDBCommandFactory interface {
	CreateDBCommand() IDBCommand
}

type IDBReader interface {
}
type IDBReaderFactory interface {
	CreateDBReader() IDBReader
}

// 对SqlServer的支持
type SqlConnection struct {
	IDBConnection
}

// 具体工厂
type SqlConnectionFactory struct {
	IDBConnectionFactory
}

type SqlCommand struct {
	IDBCommand
}
type SqlCommandFactory struct {
	IDBCommandFactory
}

type SqlDataReader struct {
	IDBReader
}

type SqlDataReaderFactory struct {
	IDBReaderFactory
}

// oracle 的支持
type OracleConnection struct {
	IDBConnection
}

type OracleConnectionFactory struct {
	IDBConnectionFactory
}

type OracleCommand struct {
	IDBCommand
}

type OracleCommandFactory struct {
	IDBCommandFactory
}

type OracleDataReader struct {
	IDBReader
}

type OracleDataReaderFactory struct {
	IDBReaderFactory
}

type Employee struct{}

type EmployeeDAO struct {
	dbConnectionFactory IDBConnectionFactory //指针
	dbCommandFactory    IDBCommandFactory
	dbReaderFactory     IDBReaderFactory
}

func (dao *EmployeeDAO) GetEmployees() []Employee {
	connection := dao.dbConnectionFactory.CreateDBConnection()
	command := dao.dbCommandFactory.CreateDBCommand()
	command.SetConnection(connection)
	return nil
}

看上去是解决了，但实际上没有体现依赖性，如果是 SQL的Connection,传给Oracle的Command，肯定会报错。

想法是把IDBConnectionFactory,IDBCommandFactory,IDBReaderFactory把这三个工厂变成一个工厂，一一对应，相干的

package abstract_factory

// 数据库访问有关的接口
type IDBConnection interface {
}

type IDBCommand interface {
	SetConnection(connection IDBConnection)
	ExecuteReader() IDBReader
}

type IDBReader interface {
	Read() bool
}

type IDBFactory interface {
	CreateDBConnection() IDBConnection
	CreateDBCommand() IDBCommand
	CreateDBReader() IDBReader
}

对于具体的数据库

package abstract_factory

import "fmt"

// 对SqlServer的支持
type SqlConnection struct {
	IDBConnection
}

type SqlCommand struct {
	IDBCommand
}

type SqlDataReader struct {
	IDBReader
}

type SqlDBFactory struct {
	IDBFactory
}

// oracle 的支持
type OracleConnection struct {
	IDBConnection
}

type OracleCommand struct {
	IDBCommand
}

type OracleDataReader struct {
	IDBReader
}

func (reader *OracleDataReader) Read() bool {
	fmt.Println("OracleDataReader Read")
	return true
}

type OracleDBFactory struct {
	IDBFactory
}

// 为工厂实现具体方法
func (factory *OracleDBFactory) CreateDBConnection() IDBConnection {
	return &OracleConnection{}
}

func (factory *OracleDBFactory) CreateDBCommand() IDBCommand {
	return &OracleCommand{}
}

func (factory *OracleDBFactory) CreateDBReader() IDBReader {
	return &OracleDataReader{}
}

type Employee struct{}

type EmployeeDAO struct {
	dbFactory IDBFactory
}

// 实例化DAO
func NewEmployeeDAO(factory IDBFactory) *EmployeeDAO {
	return &EmployeeDAO{dbFactory: factory}
}

func (dao *EmployeeDAO) GetEmployees() []Employee {
	connection := dao.dbFactory.CreateDBConnection() //同一个工厂可以保证创建的对象是同一类
	command := dao.dbFactory.CreateDBCommand()
	command.SetConnection(connection) //关联
	reader := command.ExecuteReader() //关联
	for reader.Read() {

	}
	return nil
}

总结

类图
在这里插入图片描述

  • 如果没有应对“多系列对象构建”的需求变化，则没有必要使用Abstract Factory模式，这时候使用简单的工厂完全可以。
  • “系列对象”指的是在某一特定系列下的对象之间有相互依赖、或作用的关系。不同系列的对象之间不能相互依赖。
  • Abstract Factory模式主要在于应对“新系列”的需求变动。其缺点在于难以应对“新对象”的需求变动。

原型模式

使用原型实例指定创建对象的种类，然后通过拷贝这些原型来创建新的对象

动机

  • 在软件系统中，经常面临着“某些结构复杂的对象”的创建工作；由于需求的变化，这些对象经常面临着剧烈的变化，但是它们却拥有比较稳定一致的接口。
  • 如何应对这种变化？如何向“客户程序（使用这些对象的程序）”隔离出“这些易变对象”，从而使得“依赖这些易变对象的客户程序”不随着需求改变而改变？

复杂对象，只要原型被创建了，以后需要原型都可以通过克隆实现。

而工厂方法如果创建过于复杂，不能解决中间状态，则用原型模式。

解决

原型模式将工厂方法抽取到自身，同时重命名为clone,是深拷贝！深拷贝可以通过序列化反序列化实现。

原型不是直接用的，而是通过clone创建新的对象供使用,

package prototype

import "fmt"

// 分割器的抽象
type ISplitter interface {
	split()
	clone() ISplitter //通过原型克隆自己
}

// 二进制文件分割器
type BinarySplitter struct {
	ISplitter //继承
	count     int
}

func (bin *BinarySplitter) split() {
	bin.count++
	fmt.Println("BinarySplitter split,", bin.count)

}

func (bin *BinarySplitter) clone() ISplitter {
	fmt.Println("BinarySplitter clone")

	// 通过原型克隆自己
	// 创建一个新的BinarySplitter实例，并复制原对象的属性
	clone := &BinarySplitter{}
	clone.ISplitter = bin.ISplitter
	clone.count = bin.count
	return clone
}

type MainForm struct {
	prototype ISplitter //原型对象
}

func NewMainForm(prototype ISplitter) *MainForm {
	return &MainForm{prototype: prototype}
}

func (main *MainForm) Button1_Click() {
	// 通过原型对象创建新的分割器对象
	splitter := main.prototype.clone()
	splitter.split()
}
ISplitter
+split()
+clone()
BinarySplitter
- count: int
+split()
+clone()
MainForm
- prototype: ISplitter
+Button1_Click()

总结

类图

在这里插入图片描述

  • Prototype: 模式同样用于隔离类对象的使用者和具体类型（易变类)之间的耦合关系，它同样要求这些“易变类”拥有“稳定的接口”。
  • Prototype: 模式对于“如何创建易变类的实体对象”采用“原型克隆”的方法来做，它使得我们可以非常灵活地动态创建“拥有某些稳定接口”的新对象一一所需工作仅仅是注册一个新类的对象（即原型），然后在任何需要的地方Clone。
  • Prototype: 模式中的Clone方法可以利用某些框架中的序列化来实现深拷贝。

构建器Builder

将一个复杂对象的构建与其表示相分离，使得同样的构建过程(稳定)可以创建不同的表示(变化)

动机

  • 在软件系统中，有时候面临着“一个复杂对象”的创建工作，其通常由各个部分的子对象用一定的算法构成；由于需求的变化，这个复杂对象的各个部分经常面临着剧烈的变化，但是将它们组合在一起的算法却相对稳定。
  • 如何应对这种变化？如何提供一种“封装机制”来隔离出“复杂对象的各个部分”的变化，从而保持系统中的“稳定构建算法”不随着需求改变而改变？

问题

假设有一个游戏，创建房屋，

不管怎么样的材质地基，墙壁，天花板，门、窗是需要的，流程是固定的，但具体的材料可能不一样，

package builder

type BuildPart interface {
	BuildPart01()
	BuildPart02()
	BuildPart03() bool
	BuildPart04()
	BuildPart05()
}
type House struct {
	BuildPart //是House的虚方法，必须要实现
	flag      bool
}

// 真正的构造方法
func (this *House) Init() {
	this.BuildPart01()
	for i := 0; i < 4; i++ {
		this.BuildPart02()
	}
	flag := this.BuildPart03()
	if flag {
		this.BuildPart04()
	}
	this.BuildPart05()
}

问题是由于子步骤是变化的，但是流程是固定的，所以抽离了BuildPart*。与模板方法非常像。

package builder

type BuildPart interface {
	BuildPart01()
	BuildPart02()
	BuildPart03() bool
	BuildPart04()
	BuildPart05()
}

// 房子基类
type House struct {
	BuildPart //是House的虚方法，必须要实现
}

// 真正的构造方法
func (this *House) Init() {
	this.BuildPart01()
	for i := 0; i < 4; i++ {
		this.BuildPart02()
	}
	flag := this.BuildPart03()
	if flag {
		this.BuildPart04()
	}
	this.BuildPart05()
}

// 石头房子
type StoneHouse struct {
	House //继承
}

// 实例化石头房子
func NewStoneHouse() *StoneHouse {
	stone := &StoneHouse{}
	stone.BuildPart = stone //实现了虚方法
	return stone
}

func (this *StoneHouse) BuildPart01() {
	println("StoneHouse BuildPart01")
}

func (this *StoneHouse) BuildPart02() {
	println("StoneHouse BuildPart02")
}

func (this *StoneHouse) BuildPart03() bool {
	println("StoneHouse BuildPart03")
	return true
}

func (this *StoneHouse) BuildPart04() {
	println("StoneHouse BuildPart04")
}

func (this *StoneHouse) BuildPart05() {
	println("StoneHouse BuildPart05")
}

使用

func TestHouse_Init(t *testing.T) {
	stoneHouse := NewStoneHouse()
	stoneHouse.Init()
}
House
+ BuildPart
+Init()
BuildPart
+BuildPart01()
+BuildPart02()
+BuildPart03()
+BuildPart04()
+BuildPart05()
StoneHouse
+ Inherits House
+BuildPart01()
+BuildPart02()
+BuildPart03()
+BuildPart04()
+BuildPart05()

由于有时候一个类本身功能就比较复杂，于是将Builder进一步抽离，

package builder

// 房子基类
type House struct {
	// 各种字段
	door  string
	floor string
	wall  string
	roof  string
	light string
}

type BuildPart interface {
	BuildPart01()
	BuildPart02()
	BuildPart03() bool
	BuildPart04()
	BuildPart05()
	GetResult() *House
}

// 负责构造房子的Builder
type HouseBuilder struct {
	pHouse BuildPart // 是BuildPart的虚方法，必须要实现
}

func (hb *HouseBuilder) GetResult() *House {
	return hb.pHouse.GetResult()
}

// 此前Init的具体实现，改名为Construct
type HouseDirector struct {
	pHouseBuilder BuildPart
}

// 构造器
func NewHouseDirector() *HouseDirector {
	return &HouseDirector{}
}

func (hd *HouseDirector) SetBuilder(builder BuildPart) {
	hd.pHouseBuilder = builder
}

func (hd *HouseDirector) Construct() *House {
	hd.pHouseBuilder.BuildPart01()
	for i := 0; i < 4; i++ {
		hd.pHouseBuilder.BuildPart02()
	}
	flag := hd.pHouseBuilder.BuildPart03()
	if flag {
		hd.pHouseBuilder.BuildPart04()
	}
	hd.pHouseBuilder.BuildPart05()
	return hd.pHouseBuilder.GetResult()
}

// 石头房子
type StoneHouse struct {
	House // 继承
}

// 实例化石头房子
func NewStoneHouse() *StoneHouse {
	return &StoneHouse{}
}

// 石头房子Builder
type StoneHouseBuilder struct {
	HouseBuilder // 继承
	pHouse       *StoneHouse
}

// 实例化
func NewStoneHouseBuilder(house *StoneHouse) *StoneHouseBuilder {
	stone := &StoneHouseBuilder{pHouse: house}
	return stone
}

func (shb *StoneHouseBuilder) BuildPart01() {
	println("StoneHouse BuildPart01")
	shb.pHouse.wall = "Stone"
}

func (shb *StoneHouseBuilder) BuildPart02() {
	println("StoneHouse BuildPart02")
	shb.pHouse.door = "Stone"
}

func (shb *StoneHouseBuilder) BuildPart03() bool {
	println("StoneHouse BuildPart03")
	shb.pHouse.roof = "Stone"
	return true
}

func (shb *StoneHouseBuilder) BuildPart04() {
	println("StoneHouse BuildPart04")
	shb.pHouse.floor = "Stone"
}

func (shb *StoneHouseBuilder) BuildPart05() {
	println("StoneHouse BuildPart05")
	shb.pHouse.light = "Stone"
}

func (shb *StoneHouseBuilder) GetResult() *House {
	return &shb.pHouse.House
}

这个版本太复杂，使用第一个版本也可以，使用


func TestHouse(t *testing.T) {
	director := NewHouseDirector()
	stoneHouseBuilder := NewStoneHouseBuilder(NewStoneHouse())
	director.SetBuilder(stoneHouseBuilder)
	house := director.Construct()
	fmt.Printf("%+v\n", house)
}

总结

在这里插入图片描述

  • Builder 模式主要用于“分步骤构建一个复杂的对象”。在这其中“分步骤”是一个稳定的算法，而复杂对象的各个部分则经常变化。
  • 变化点在哪里，封装哪里—— Builder模式主要在于应对“复杂对象各个部分”的频繁需求变动。其缺点在于难以应对“分步骤构建算法”的需求变动。
  • 在Builder模式中，要注意不同语言中构造器内调用虚函数的差别（C++ vs. C#) 。
都学点
关注
  • 0
    点赞
  • 踩
  • 0
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 0
    评论
专栏目录
JavaScript对象创建模式实例汇总
10-21
主要介绍了JavaScript对象创建模式,结合实例形式总结分析了JavaScript常见的对象创建模式,包括工厂模式、构造函数模式、原型模式、动态原型模式、寄生构造函数模式、稳妥构造函数模式等,需要的朋友可以参考下
js 创建对象 经典模式全面了解
10-21
下面小编就为大家带来一篇js 创建对象 经典模式全面了解。小编觉得挺不错的，现在就分享给大家，也给大家做个参考。一起跟随小编过来看看吧
JS 创建对象的模式实例小结
10-15
不同的创建模式提供了不同的灵活性和适用场景。以下是对给定标题和描述中提到的几种JS创建对象模式的详细说明： 1. **工厂模式**： 工厂模式的主要目的是通过一个函数来创建具有相同属性和方法的对象，而隐藏具体...
JavaScript中创建对象的模式汇总
10-22
本文给大家js创建对象的模式包括对象字面量，工厂模式，构造函数模式，原型模式，结合构造函数和原型模式，原型动态模式 ，感兴趣的朋友参考下
go 实现websocket以及详细设计流程过程，确保通俗易懂
每天进步一点
07-17 888
数据只能单向传送为单工；数据能双向传送但不能同时双向传送称为半双工；数据能够同时双向传送则称为全双工。上面是简单的接受了websocket情况以及和其他协议的区别及联系，在做之前，还是要了解下这块，对后期实战有帮助。
golang小案例获取命令行的的参数并求得最大值
preserveXing的博客
07-15 229
这个案例是Golang理解os.Args的案例 场景就是: 当我们打包后 生成的.exe文件 执行exe肯定会出现哪些命令 例如 npm install app 这里的npm 就是npm .exe install app 就是我们要获取的参数 我们的案例: 编写go程序---->打包成exe--->执行exe--->添加命令行参数 一些数值---->求得最大化数值
Go: IM系统技术架构梳理 (2)
Wang的专栏
07-15 1082
整个IM系统的一般架构如下我们这张图展示了整个IM系统的一般架构可见分为四层那最上面这一层是前端，包括哪些东西呢？它包括两部分，第一部分是跟用户直接交互的比如说各种IOS APP, 各种安卓 APP还有各种 web APP 在浏览器里面打开的以及windows上面跑的那种客户端第二部分是跟我们程序相关的SDK，API，Websocket这些我们都统称为前端第二个是接入层，这里展示了几种常用的接入协议实际上还会用到Mqtt, Xmpp 等各种协议这是接入层。
解决 go 引用私有包，安装失败
Dreamy_LIN的博客
07-17 213
go mod tidy 或者 go run main.go 时，提示失败，例如 no such host（设置GOPRIVATE）或者 x509: certificate signed by unknown authority 之类的报错（设置GOINSECURE）
Golang中读写锁的底层实现
qq_42538588的博客
07-16 781
读写锁是一种并发控制机制，它允许多个线程同时对共享资源进行读访问，但在进行写操作时需要互斥访问，以确保数据的一致性和完整性。读写锁的主要功能是提高系统在读多写少场景下的并发处理能力，从而提升整体性能。读写锁在实际应用中扮演着重要的角色，可以有效地降低系统的并发访问冲突，提高系统的并发处理能力，同时也能够避免写操作对读操作的阻塞，从而减少了线程的等待时间，提升了系统的整体响应速度。w Mutex // 互斥锁L *Locker本文介绍了如何在Go语言中使用读写锁的应用实例。
go-zero框架入门
qq_63728673的博客
07-18 560
使用 Raft 共识算法**，确保了在分布式环境中的强一致性**。再举个例子：正常项目中配置文件写在代码中，若配置文件修改，项目就该重新启动，但是若使用了etcd，每次去查看对应RPC的配置信息时都是从etcd中实时获取。并且etcd本身为分布式系统设计，提供了原生的服务发现和配置管理功能，支持 Watch 机制，可以。之后打开一个命令行窗口，输入：etcd就可以启动了，然后再打开一个黑窗口（上一个不要关）这就是go-zero使用前的前置工作了，下一步就是去写简单的项目。1.在根目录下创建一个user包。
golang mux组件兼容转移url
国产-达芬奇
07-16 229
UseEncodedPath
GO——GMP 好文整理
sy_123a的专栏
07-17 190
GMP相关好文推荐：Golang的协程调度器原理及GMP设计思想
goLang 通过 Select + Channels 实现定时任务与调度
JineD的博客
07-15 319
time 包 在与 channel 结合时提供了很多有用的功能，其中 time.Ticker 结构体能够处理定时事件，它会定期在指定 channel 上发送时间值。在这篇文章中，我们深入探讨了如何使用 Go 语言中的 time 包与 channel 结合来处理定时事件和任务调度。通过 time.Ticker 结构体的周期性触发和 select 语句的多路复用能力，我们可以创建高效且响应迅速的定时任务处理系统。Ticker 对于在 goroutine 中周期性执行任务（如日志记录或计算）非常方便。
【golang-ent】go-zero框架 整合 ent orm框架 | 解决left join未关联报错的问题
CTRA®王大大技术中心
07-18 248
【golang-ent】go-zero框架 整合 ent orm框架 | 解决left join未关联报错的问题
golang开发环境搭建与踩坑记录
秃了也弱了
07-18 269
函数通常在最后的返回值中返回错误信息。我们可以在编码中通过实现 error 接口类型来生成错误信息。在指针类型前面加上 * 号（前缀）来获取指针所指向的内容。windows直接下载msi文件安装即可。多级指针本质上就是一个指针链。指针变量只能指向一个地址。
Go语言并发编程-Context上下文
最新发布
choice~的博客
07-18 722
Go 1.7 标准库引入 context，译作“上下文”，准确说它是 goroutine 的上下文，包含 goroutine 的运行状态、环境、现场等信息。context 主要用来在 goroutine 之间传递上下文信息，包括：取消信号、超时时间、截止时间、k-v 等。随着 context 包的引入，标准库中很多接口因此加上了 context 参数，例如 database/sql 包。context 几乎成为了并发控制和超时控制的标准做法。。
Go 语言 UUID 库 google/uuid 源码解析：UUID version7 的实现
CodeSingerAlex的博客
07-15 1128
本篇文章介绍 UUID 的推荐使用版本 UUIDv7 的特性与结构，并对 google/uuid 中实现 UUIDv7 的源代码进行解析。通过此篇文章，你将会对 UUIDv7 产生更深刻的认识。
k8s之client-go：golang与k8s交互的桥梁
https://gitee.com/zm50
07-14 491
k8s是一个非常成熟且强大的容器自动化编排引擎，对于这样一个利器，k8s官方提供了clientgo用来给我们使用golang去接入k8s，通过k8s的api来对k8s中的资源进行操作通过client-go实现对k8s集群中资源对象(包括deployment、service、ingress、replicaSet、pod、namespace、node等)的增删改查等操作我们演示了一个简单的例子，来描述client-go的基本用法，希望对你有所帮助。
工厂模式：封装对象创建过程
"这篇内容主要讨论了软件设计模式中的工厂模式，以及如何通过该模式解决对象创建中的问题。" 在软件开发中，工厂模式是一种常用的设计模式，它提供了一种封装对象创建的方式，使得客户端代码无需直接指定所创建对象...

“相关推荐”对你有帮助么？

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

都学点

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付：¥1
获取中
扫码支付

您的余额不足，请更换扫码支付或充值

打赏作者

实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值