浅谈设计模式

作为一个苦逼码农,请先回顾自己是否遇到过以下场景:

 1.我要实现的这个特性中有一些被频繁使用的代码,并且在其它特性中也被用到了,我不想总是做重复的事,那样费力且容易出错,因此需要一种方法能把这些稳固的代码抽象出来。 

2.这两个模块耦合太紧密了,代码一团糟,你中有我,我中有你,真令人抓狂!有什么办法彻底解耦吗?

 3.有一位兄弟的代码经过测试功能无误,但他的实现思路很奇怪,可读性差。我有更好的方法,但是必须首先说服他接受我的意见,我该拿出怎样权威的理由证明给他看呢? 

4.常听到有人抱怨说软件实现太灵活了,每个人都有不同的思路。那么如何才能让一个团队的代码看起来犹如同一个人写的那样,具有良好的可读性和可维护性呢? 

Talk is Cheap,show me the code! 先来看一个例子:当一个接口被删除之后,在引用它的模块中也要删除对应的记录。 一个新手可能会写下这样的代码:

 unsigned int funcx_remove(const char name) {

 struct nic_t * funcx = nic_get(hash(name)); / 删除对应模块的entry /

module1_del_entry_for(funcx); 

return nic_free(funcx);

 }

 目前看,这样做没有什么问题。但有一天,但是你还没有舒服几天,就收到一个问题单,说module2/module3里对应于funcx的内容没有删除!Oh,天哪!你认为不应该再这样下去了。于是你想出来一个妙招:他强由他强,清风拂山岗;他横任他横,明月照大江 

在系统中构造了一条“事件通知链”,谁对删除funcx这个事件感兴趣,就把自己的处理动作挂到链上。这样一来,funcx_delete()就不再和具体的模块耦合,问题单不会再压到你的头上。

 unsigned int funcx_remove(const char *name) {

 struct nic_t *nic = nic_get(hash(name)); / 把事件通知到系统 ,不关心接受者都有谁 */ 

nic_event_notify(funcx_REMOVED, nic); return nic_free(nic); } 然后你放一个注册接口出来,谁对这个事件感兴趣就自己注册吧,别再烦我 void register_event_notifier(struct notifier_hook_t notify);

}

设计模式要干啥?设计模式的本质是职责的分离,职责不是天生的,如何去分离职责?这才是发力的重点,培养对“职责”的敏感度和基本思考技巧,设计模式要做的,就是把代码中相对稳定的部分和剧烈变动的部分解耦,从而将变化对代码产生的影响局限在小范围内。

上个例子中就是一个观察者模式,把事件发生,和对应的动作分离,事件发生了,我就根据对应的注册信息通知到所有关注者,而具体的动作,由关注者自己做。 经典的Gof设计模式有三类二十三种,它们可以分为:创建型,结构型和行为型,这篇文章作为开始,陆续总结,但是要提醒的是,不要试图在你的代码中全方位地套用设计模式,熟练地运用几种模式来解决问题就足够了。模式只是手段,用高内聚,低耦合的代码为业务服务才是每一位程序员追求的目标。

你可能感兴趣的:(浅谈设计模式)