golang进阶介绍part-3(布局的概念)

字数 1822阅读 601

前言

  之前介绍了一些Golang的基础使用,从学习的角度上demo化了比较重要的几个要点,这一篇主要介绍一些从个人角度以及开发习惯上对于Golang布局的理解。

1. (golang package) vs (.net nuget/ java jar )

  我本人之前是一个csharper,第一门接触的语言是php,所以在学golang的时候会不自觉的是用传统概念的三层架构去理解golang的布局,有的时候会发现,怎么写代码是如此的变扭,越写越怀疑golang这语言写起来怎么那么尴尬,为此我特地问了些先行者,也网上看了一些golang如何布局的帖子,最后我总结了原因,后来别人问我我都是那么回答的,可能有不足之处。
   golang的package的导包比较特殊,当import了一个package后,该package的东西就可以使用了,这在我看来有点类似于领域驱动的概念,又有点组件化的概念,也和golang的特性直接相关,因为Golang的interface编程更贴合组装式的。
  java或者.net则是继承式的,当然也有interface的概念,但是因为有天然的继承,所以interface也会向继承的概念侧重,并且目前最流行的IOC的编程,更加让这些语言向继承倾斜,所以他们的包管理适合全量,简单的项目分类可以侧重model, business,data式的分层。
  这恰恰是该类开发者转golang的缺点所在,因为对于这样的编程模式太熟悉了,导致概念的转换显得有些笨拙。
  golang的import式编程目的在于让项目按功能块划分的更细,一个小业务块有一个自己的包,多包之间可以是并列的,更像最近火起的微服务概念的抽想,我们可以通过golang开源项目docker(现在叫moby)的开源库来理解,其中container和image各有一个属于自己的包,如果以java或者.net来,很可能这2个都是model层的一个class了。
  在我自己的编写的项目中,我是这样理解的,拿区块链钱包举例,币种的概念和交易以及公私钥和后台爬块这4个点我会抽象成 coin、trans、key、daemon,这样开源后,如果别人感觉我的coin包写的好,那么就直接借用吧,并不需要其他3个包,如果他觉得key的公私钥管理包很适合他,其他的没有可取之处,那么走您,import key包。
  golang更考验开发者对于对象化概念的抽象,如何量化一个package的边界,如何实现package之间的依赖,这些都是学问。

2. interface 与 struct 结合使用

  • 相对于面向对象的封装、继承、多态,还是以区块链为例,多种主链币之间,每个币种也业务实现都有一定自由规则,但是概念上区块链交易概念是类似的,我们可以接口化约束币种钱包的功能,使得更易于业务逻辑的管理
type BTC struct{
}
type ETH struct{
}
type Walleter interface {
      Transfer()
      GetBalance(account string)int
}
func(*BTC)Transfer(){
}
func(*BTC)GetBalance(account string)int{
}
func(*ETH)Transfer(){
}
func(*ETH)GetBalance(account string)int{
}

因为上面的封装,我们可以使主流程单一化,另外一点interface把一个业务块的逻辑体现在了几行简短的代码块中,也是对业务梳理的一个提纲,一个目录,所以即使不是多态的概念,也可以适当的运用interface。

  • 然而有时候我们还会需要数据库的操作
type UserStorage struct{
    Save(account string,balance int)
    Remove()
}
type BlockChain struct{
      db    *UserStorage
     Walleter
}

func(bc *BlockChain)GetBalance(account string){
     bal := bc.Walleter.GetBalance(account)    
     bc.db.Save(account,bal)   
}

如此封装的好处在于db的引用全是在BlockChain内部的,方便存储介质的替换,相比于db逻辑传参进来更易于维护和拓展,如果有BlockChain,BlockChain1,BlockChain2都这样使用,那么我们替换BlockChain1时,不管是查找引用,还是模块化替换都更加工程化。

  • 另一外一个interface的妙用就是,将struct解除对外的暴露,直接暴露interface,所有需要对外提供的数据都已interface的func对外返回,如果开发者觉暴露struct会导致其他开发者调用中引起问题的话。
type core struct{
}
type Corer interface{
    GetCoreNum()
    SetCoreName()
}
func NewCore()Corer{
}

3. go和channel的使用

  这2个是Golang的一个关键点所在,具体原理我在golang 基础介绍part-2中介绍过,然而对于go和channel的使用,我个人认为,一定要在把控好的基础上使用,比如go并发量一旦大过头了可能会让数据库读写跟不上,channel乱用会导致一个流程不见底,这些都会导致代码的后期拓展和维护存在大问题,一个项目的好坏是把复杂的逻辑写的更简单易懂,大道若简,而不是为了炫技把一个简单的逻辑复杂化导致维护拓展成本的上升

4. 单元测试,性能测试

  关于单元测试,很多程序员都不喜欢自己写,当初我在开发.NET项目时,起初也是认为我的代码没问题,我能通过自己的方法确保他是OK的,但是在开发过程中,其实变相的还是写了很多单元测试,因为要确保逻辑通啊,方便修改啊,方便调试啊,在golang项目中,test的编写更加容易,单元测试的编写能够让你设计的项目结构依赖更顺畅,如果单元测试不好写,那么就说明项目结构有问题了,需要反思一下了,如何才能让单元测试的编写更简单,这也是一个反哺的过程,编写单元测试越容易说明代码结构解耦的越好,越健壮。
  性能测试也是不得不提的一个点,在代码优化时,他能计算出的在并行状态下的运算时间,消耗了多少内存,实例化了多少个对象等等,能让人更好的把控自己的代码,同时也加深了对于Golang原理的了解,有助于编写出更加优秀的代码。

对于单元测试的数据及启动项,我个人习惯加一个Mock包用作全局测试数据的管理,全局的test直接应用这个包使用依赖或者数据,这样整个项目的启动依赖也体现在了mock包中,这样测试和实际就牢牢结合在了一起。

5. 项目结构方面

Golang 标准包布局[译]
这边篇子很好。

推荐阅读更多精彩内容