golang and design pattern

学习java的时候,“设计模式”这个概念到处可见。比如java.io里面的 decorated pattern,Object.Clone(Object)原生态支持Prototype pattern,Swing事件响应的Observer pattern, io.util和Event中的Adapter pattern。还有第三方框架中形形色色的design pattern。有时候从代码中突然发现一个design pattern,喜不自禁。

现在学习go语言,就再也没有从go语言中听到design pattern这个概念了。design pattern本身就是 Object-Oriented语言在实践的经验总结。在pure Object-Oriented语言如Java中自然运用得淋漓尽致,而在hybrid Object-Oriented语言C++中相对运用得少些,在在以互联网时代的C语言自居的go中,几乎听不到design pattern这个概念。

虽然,毕业后我基本没有再写过java,但是在工作和学习中经常能够突然发现设计模式的运用。瞬间有种茅塞顿开之感。为了记住这些时刻,我先把几个在心头的案例记下来,同时留下几个坑,以后慢慢填坑。

Case 1:

工作中发现 有些地方经常会使用

hr = stream.SaveToStream( xXXInstance);

check(hr)

...

hr = stream.ReadFromStream(xNewInstance)

check(hr)

刚开始接触这个代码的时候,比较疑惑,不太明白它在做什么。分析后发现这是在copy对象,但是觉得它在简单问题复杂化。后来一次读到一本讲解设计模式的书,在书中Prototype pattern一章提到deep copy的一种实现方式,当时豁然开朗,突然明白了这段代码的意图。

Case 2:

Go的bufio可谓把decorated pattern 发挥得淋漓尽致。这个和java的io pattern类似。

Case 3:

最近再学一下Go语言http package, 读谢孟军的《Go Web编程》时,发现其中一节描述rountine 时,演示的代码与我记忆中Go 1.4 的源码不一样。又回去查看了一下源码,确定了我的怀疑是对的。

言归正传,继续回到design pattern。还是用代码说话

// Objects implementing the Handler interface can be
// registered to serve a particular path or subtree
// in the HTTP server.
//
type Handler interface {
    ServeHTTP(ResponseWriter, *Request)
}

func (mux *ServeMux) handler(r *Requst) Handler {
    ...
}

mux.Handler(r).ServerHTTP(w, r)

上图中,实现Handler接口的可以作为Route的某一个项(Entry)注册到Route即ServeMux中去,路由过程中,

我们先根据request信息提取对应的Entry,

mux.Handler(r).

然后在Entry上面调用服务

ServerHTTP(w, r)

现在Go1.4 中也让ServeMux实现了

type Handler interface {
    ServeHTTP(ResponseWriter, *Request)
}

现在把所有路由直接交给ServeMux处理,ServeMux自己负责细节处理

// ServeHTTP dispatches the request to the handler whose
// pattern most closely matches the request URL.
func (mux *ServeMux) ServeHTTP(w ResponseWriter, r *Request) {
    if r.RequestURI == "*" {
        if r.ProtoAtLeast(1, 1) {
            w.Header().Set("Connection", "close")
        }
        w.WriteHeader(StatusBadRequest)
        return
    }
    h, _ := mux.Handler(r)
    h.ServeHTTP(w, r)
}

// Serve a new connection.
func (c *conn) serve() {
    ...

    for {
        w, err := c.readRequest()
        ...

        ...
        serverHandler{c.server}.ServeHTTP(w, w.req)
                ...

    }
}            

其中

serverHandler{c.server}.ServeHTTP(w, w.req)

委托server 中的ServeMutext的ServeHTTP方法。

有点像Composite pattern吧。

case 4:

go语言中函数地位提升,为一等对象。我们经常可以看到其利用闭包实现,传人函数实现工厂方法。

先留下坑,下次代码补上。

时间: 2024-10-13 02:57:02

golang and design pattern的相关文章

DP什么意思 design pattern 设计模式

DP  design pattern 大话设计模式  中的DP 是设计模式的意思 设计模式的书 ,最经典最原始的就是 GOF 的<设计模式>了. 设计模式的书基本上大多是以这 20 多个模式分开讲.含<大话设计模式> 学了 OOL 写的程序基本上是 OB 的. 只有慢慢掌握了 DP 才能写出真正的 OO 程序. 思想 -> 设计原则 -> DP -> OOD

Head First Design Pattern 读书笔记(2) 观察者模式

Head First Design Pattern 读书笔记(2) Observer Pattern 观察者模式 Observer Pattern 类图 定义 观察者模式:在对象间定义一个一对多的关系,当其中一个的对象发生改变时,所有依赖于这个对象的对象(即观察者们)都会自动更新或做执行某些行为. 几个OO的原测 尽量以松耦合的方式处理对象间关系–>软件工程时候学的"高內聚,低耦合"的好处 关于观察者模式 被观察对象通知观察者可以使用推送的方式(类图中带参数的notifyActi

Design Pattern Singleton 单一模式

单一模式的几个注意点: 一) 设计单一模式,首先需要把构造函数给私有化了,不让外界访问,那么外界只能通过提供的函数获取一个新的类. 二) C++的单一模式,记得要在类外初始化一个类,否则或内存出错的. 三) 这个唯一的类必须是要静态的 程序: #ifndef _SINGLETON_H #define _SINGLETON_H #include <iostream> #include <string> using namespace std; class DuGuJiuJian {

Design Pattern 设计模式1 - Strategy 1

实现 : Defferent Heros attack Defferently. - 不同的英雄使用不用的招数 Strategy设计的思路: 基类A,更加小的基类B,新的继承类C: 1 从基类A中抽出一个更加小的基类B 2 利用这个更加小的基类B实现不同的效果 3 把这个更加小的基类B包含进基类A中去 4 新的继承类C只需要和基类A打交道,设计不同行为,不需要理会更加小的基类B #pragma once #ifndef _STRATEGY_HEROS_H #define _STRATEGY_HE

简单工厂设计模式(Simple Factory Design Pattern)

[引言]最近在Youtub上面看到一个讲解.net设计模式的视频,其中作者的一个理解让我印象很深刻:所谓的设计模式其实就是运用面向对象编程的思想来解决平时代码中的紧耦合,低扩展的问题.另外一点比较有见解的是,区分了设计模式(Design Pattern),结构模式(Architecture Pattern),架构类型(Architecture Style). 如下图所示 Design Pattern:是基于代码层面的,就是针对解决功能模块之间的问题而采用恰当的设计模式,比如依赖注入,简单工厂,适

Design Pattern —— Singleton

Design Pattern —— Singleton   强力推荐枚举和类级内部类方式实现单例模式 单例模式是开发中非常常用的一种模式,简单的说,我们希望一个类永远都只有一个对象. 主要有两个用途: 1.存储一些进程内共享的值(不是很推荐,大部分情况下还是应该用局部变量,互相传递值的方式) 2.任何时候都不变的操作 单例模式的实现目前已知的有五种: 1.饿汉式 2.懒汉式 3.双重验证 4.类级内部类 5.枚举 一.饿汉式 类加载时就创建好对象,以空间换时间.这样外部调用EagerSingle

Head First Design Pattern 读书笔记(1) 策略模式

Head First Design Pattern 读书笔记(1) Strategy Pattern 策略模式 这几天为了锻炼看英语文档的能力,开着有道硬着头皮看 <Head First Desgin Pattern>的原版书,顺便做下笔记,把里面提到的每个模式通过回忆的方式画出来复习并记下来总结下学习成果=.= 关于设计模式 使用设计模式是为了增强程序的复用性,拓展性,易维护性. 设计模式会增加程序代码的复杂度,并不是所有情况都必须使用设计模式,需要根据需求以及经验评估使用场景. 学习并掌握

State Design Pattern 状态设计模式

设置好内部状态,然后根据不同的函数作为行为模式,进行状态转换. 有点像Finite Automata算法,两者的思想是一样的. 会Finite Automata,那么这个设计模式就很容易了. #pragma once #include <stdlib.h> #include <math.h> #include <random> #include <time.h> enum STATES { FULLY_RENTED, WAITING, GOT_APPLICA

UML for Design Pattern

************************************************************************************* ************************************************************************************* ******************************************************************************