关于后端:大话设计模式今天你设计了吗

背景

在开发过程中你是否有遇到过这样的苦恼?产品发来一个需要,没做过,然而看完需要感觉应该解决起来很简略,而后找到对应的业务代码,发现代码像打乱的毛线一样理不分明,各种逻辑嵌套,各种非凡判断解决,想要拓展保护个内容却无从下手,一边看着代码,一边用手拨动着本就为数不多的秀发,而后口吐芳香 。

有没发现一个问题,为什么业务不简单,然而随着产品迭代,通过一直拓展和保护,缓缓的代码就越做越乱,你能够说产品想法天马星空,人员流动大,多人参加缓缓的就被做乱了,这可能是个不错的借口,然而其中实质的问题还是后期思考的太少,没有进行正当的形象设计,没有去前瞻性的去预埋一些将来可拓展性的内容,所以最终导致了起初的场面。

常常听到有教训的开发者说开发前多思考,不要一拿到需要就习惯性的一顿操作,反手就定义一个function依据需要逻辑一条龙写到底。

所以面对绝对简单的需要咱们须要进行形象思考,尽可能做到设计进去的货色是解决一类问题,而不是单单解决以后问题,而后在代码实现上也要面向形象开发,这样能力做到真正的高质量代码,可维护性和可拓展性高,能力积淀出可复用,健壮性强的零碎。

那么咱们要如何去形象呢?面对需要的抽象思维这个须要平时多锤炼,拿到需要多想多思考,不要急于求成,次要围绕着这几大因素:可维护性、可拓展性、可复用性,安全性去设计解决方案,至于代码上的形象就能够应用上面的形式。

不卖关子了,是时候请出明天的配角:《设计模式》,简略的说设计模式就是开发者们的教训积淀,通过学习设计模式并在业务开发过程中加以应用,能够让代码的实现更容易拓展和保护,进步整体代码品质,也能够作为开发之间沟通的专业术语,提到某个模式,能够马上get到代码设计,缩小沟通的老本。

这里就不一一介绍23种设计模式和设计模式的6个准则,能够google回顾下
举荐:学习设计模式地址

上面就将联合以后我的项目的bad case,手把手的应用设计模式进行重构,其中会用到多种设计模式的应用,并且体现了设计模式的中的几个准则,做好筹备,发车了。

举例

需要背景概要:

APP首页性能,用模块化的形式去治理配置,后盾能够配置模块标识和模块排序,展现条件等,首页API接口获取以后用户的模块列表,并结构模块数据展现。

API Response Data

伪响应数据,疏忽掉不重要或者反复的数据

{
    "code": 0,
    "data": {
        "tools": {
            // -- 模块信息 --
            "id": 744,
            "icon": "",
            "name": "",
            "sub_title": "",
            "module": "lm_tools",
            "sort": 1,
            "is_lock": true,
            "is_show": true,
            "more_text": "",
            "more_uri": "xxx:///tools/more",
            "list": [
                // -- 模块展现数据 --
            ]
        },
        "my_baby": {
            // ... ...
        },
        "knowledge_parenting": {
            // ... ...
        },
        "early_due": {
            // ... ...
        },

        // ... ...

        "message": ""
}

Before Code

伪代码,疏忽掉一些不重要的code

func (hm *HomeModule) GetHomeData() map[string]interface{} {
  result := make(map[string]interface{})
    // ... ...

    // 获取模块列表
    module := lm.GetHomeSortData()

    // ... ...

    // 结构每个模块的数据
    for _, module := range moduleList {
        // ... ...
        switch module.Module {
        case "my_baby":
            // ... ...
            result["my_baby"] = data
        case "lm_tools":
            // ... ...
            result["lm_tools"] = data
        case "weight":
            // ... ...
            result["weight"] = data
        case "diagnose":
                result["diagnose"] = data
        case "weather":
            // ... ...
            result["weather"] = data
        case "early_edu":
            // ... ...
            result["early_edu"] = data
        case "today_knowledge":
            // ... ...
            data["tips"]=list
            // ... ...
            data["life_video"]=lifeVideo
            // ... ...
            result["today_knowledge"] = data
        default:
            result[module.Module] = module
        }
        // ... ...
        return result
    }

看完这个代码,是否有一种要坏起来的滋味,随着模块一直减少,case会越来越多,而且每个case外面又有一些针对版本、针对AB、一些非凡解决等,让代码变得又臭又长,越来越难去拓展和保护,并且每次保护或者拓展都可能在GetHomeData() 办法里在一直往里面添枝加叶,不小心就会对整个接口产生影响。

那么咱们要如何去重构呢,这就要形象起来,这个业务自身就曾经有模块相干形象设计,这里就不进行调整,次要是针对代码上的形象,联合设计模式进行革新。

以下就是重构的过程。

刚开始的时候,看到这种case 判断,而后做模块数据的聚合,我第一反馈是,是否能够应用工厂模式,定义一个 interface,每个模块定义一个struct 实现接口ExportData() 办法,通过工厂办法去依据模块标识创建对象,而后调用导出数据办法进行数据上的聚合 。

然而在评估的过程中,发现有些模块数据里又聚合了多个不同业务知识内容的数据,单纯的工厂模式又不太适合,最初决定应用组合模式,结构型设计模式,能够将对象进行组合,实现一个相似层级对象关系,如:

# 首页模块
home
    - my_baby
    - weight
    - early_edu
    - today_knowledge
        - tips
        - life_video
    - weather
    - ... ...

这里我从新定义了下名词,后盾配置的是模块,在代码实现上我把每个模块里展现的数据定义成 组件,组件又能够分成 繁多组件 和 复合组件,复合组件就是应用了多个繁多组件组成。

UML结构图:

Refactor After Code:

定义组件接口 IElement :

// IElement 组件接口
type IElement interface {
    // Add 增加组件,繁多组件,能够不必实现具体方法内容
    Add(compUni string, compo IElement)
    // ExportData 输入组件数据
    ExportData(parameter map[string]interface{}) (interface{}, error)
}

定义组件类型枚举

// EElement 组件类型
type EElement string

const (
    EElementTips             EElement = "tips"            // 贴士
    EElementLifeVideo        EElement = "life_video"      // 生命一千天
    EElementEarlyEdu         EElement = "early_edu"       // 早教
    EElementBaby              EElement = "baby"             // 宝宝
    ECompositeTodayKnowledge EElement = "today_knowledge" // 今日常识
    // ....
)

func (ec EElement) ToStr() string {
    return string(ec)
}

繁多组件的实现

// ElemTips 贴士组件
type ElemTips struct {
}

func NewCompoTips() *ElementTips {
    return &ElementTips{}
}

func (c *ElementTips) Add(compoUni string, comp IElement) {
}

func (c ElementTips) ExportData(parameter map[string]interface{}) (interface{}, error) {
    tips := []map[string]interface{}{
        {
            "id":    1,
            "title": "贴士1",
        },
        {
            "id":    2,
            "title": "贴士2",
        },
        {
            "id":    3,
            "title": "贴士3",
        },
        {
            "id":    4,
            "title": "贴士4",
        },
    }

    return tips, nil
}

// ElemLifeVideo 生命一千天组件
type ElemLifeVideo struct {
}

func NewCompoLifeVideo() *ElementLifeVideo {
    return &ElementLifeVideo{}
}

func (c ElementLifeVideo) Add(compoUni string, comp IElement) {
}

func (c ElementLifeVideo) ExportData(parameter map[string]interface{}) (interface{}, error) {
    lifeVideos := []map[string]interface{}{
        {
            "id":    1,
            "title": "生命一千天1",
        },
        {
            "id":    2,
            "title": "生命一千天2",
        },
        {
            "id":    3,
            "title": "生命一千天3",
        },
        {
            "id":    4,
            "title": "生命一千天4",
        },
    }
    return lifeVideos, nil
}

// ... ...

复合组件:

// 今日常识,组合多个dan'yi组件
type ElemTodayKnowledge struct {
    Composite map[string]IElement
}

func NewCompoTodayKnowledge() *ElemTodayKnowledge {
    factory := NewElementFactory()
    c := new(ElemTodayKnowledge)
    c.Add(EElementTips.ToStr(), factory.CreateElement(EElementTips.ToStr()))
    c.Add(EElementEarlyEdu.ToStr(), factory.CreateElement(EElementEarlyEdu.ToStr()))
    return c
}

func (c *ElemTodayKnowledge) Add(compoUni string, comp IElement) {
    if c.Composite == nil {
        c.Composite = map[string]IElement{}
    }
    c.Composite[compoUni] = comp
}

func (c ElemTodayKnowledge) ExportData(parameter map[string]interface{}) (interface{}, error) {
    data := map[string]interface{}{}
    for uni, compo := range c.Composite {
        data[uni], _ = compo.ExportData(parameter)
    }
    return data, nil
}

因为有些常识数据的内容曾经有相干实现,并且能够结构对象进行调用,咱们须要做的是依据组件需要适配成组件须要的数据结构进行输入,这里又引入了适配器模式,能够应用适配器模式,将其适配成以后组件须要的数据结构输入。

// ElemEarlyDduAdapter 早教组件 - 适配
type ElemEarlyDduAdapter struct {
    edu earlyEdu.ThemeManager
}

func NewElementLifeVideoAdapter(edu earlyEdu.ThemeManager) *ElemEarlyDduAdapter {
    return &ElemEarlyDduAdapter{edu: edu}
}

func (c ElemEarlyDduAdapter) Add(compoUni string, comp IElement) {
}

func (c ElemEarlyDduAdapter) ExportData(parameter map[string]interface{}) (interface{}, error) {
    age, ok := parameter["age"].(uint32)
    if !ok {
        return nil, errors.New("短少age")
    }
    birthday, ok := parameter["birthday"].(string)
    if !ok {
        return nil, errors.New("短少birthday")
    }
    list := c.edu.GetList(age, birthday)
    return list, nil
}

对象的创立须要进行对立治理,便于后续的拓展和替换,这里引入工厂模式,封装组件的对象创立,通过工厂办法去创立组件对象。

// ElemFactory 组件工厂
type ElemFactory struct {
}

func NewElementFactory() *ElemFactory {
    return &ElemFactory{}
}

// CreateElement 内容组件对象工厂
func (e ElemFactory) CreateElement(compType string) IElement {
    switch compType {
    case EElementBaby.ToStr():
        return NewCompoBaby()
    case EElementEarlyEdu.ToStr():
        return NewElementLifeVideoAdapter(earlyEdu.ThemeManager{})
    case EElementLifeVideo.ToStr():
        return NewCompoLifeVideo()
    case EElementTips.ToStr():
        return NewCompoTips()
    case ECompositeTodayKnowledge.ToStr():
        return NewCompoTodayKnowledge()
    default:
        return nil
    }
}

辣妈首页模块数据聚合:

type HomeModule struct {
    GCtx *gin.Context
}

func NewHomeModule(ctx *gin.Context) *HomeModule {
    // 构建模块对象
    lh := &HomeModule{
        GCtx: ctx,
    }
    return lh
}

func (lh HomeModule) GetHomeModules() interface{} {

    // 请request context 上文获取申请参数
    parameter := map[string]interface{}{
        "baby_id":  22000025,
        "birthday": "2021-12-11",
        "age":      uint32(10),
        // ... ...
    }

    // 从db获取模块列表
    compos := []string{
        "early_edu",
        "baby",
        "tips",
        "today_knowledge",
    }

    // 组装组件
    elements := map[string]element.IElement{}
    elementFactory := element.NewElementFactory()
    for _, compoUni := range compos {
        comp := elementFactory.CreateElement(compoUni)
        if comp == nil {
            continue
        }
        elements[compoUni] = comp
    }

    // 聚合数据
    data := map[string]interface{}{}
    for uni, compo := range elements {
        data[uni], _ = compo.ExportData(parameter)
    }

    return data
}

革新相干内容,over ~

通过革新,后续再拓展或者保护首页模块数据的时候,根本不须要动到获取数据的办法:GetHomeModules() ,拓展的时候只须要去拓展一个组件枚举类型,而后定义组件 struct 实现 组件接口 IElement 办法,在组件工厂 ElemFactory 中拓展对象创立,保护组件的时候也只须要对ExportData() 批改。

这次的重构计划中体现了设计模式的几个准则,咱们形象了组件接口,针对接口编程,不针对实现编程,满足接口隔离准则,并且对批改敞开,对拓展凋谢,满足了开闭准则。

总结:

最初,为了缩小反复的代码开发,防止做添枝加叶的事件,为了我的项目的可维护性,可拓展性,也防止成为后人口吐芳香的对象,咱们须要设计起来,实现能够应答变动,有弹性的零碎。

评论

发表回复

您的邮箱地址不会被公开。 必填项已用 * 标注

这个站点使用 Akismet 来减少垃圾评论。了解你的评论数据如何被处理