一亩三分地论坛

 找回密码
 获取更多干货,去instant注册!

扫码关注一亩三分地公众号
查看: 2693|回复: 4
收起左侧

[系统设计/OOD] 稍微讲两句关于OOD的闲话吧。。关于怎么学,扯淡,以及怎么用

[复制链接] |试试Instant~ |关注本帖
staycrazy 发表于 2016-3-9 03:46:41 | 显示全部楼层 |阅读模式

注册一亩三分地论坛,查看更多干货!

您需要 登录 才可以下载或查看,没有帐号?获取更多干货,去instant注册!

x
家里有事,消失了一段时间,现在把当初说过的要总结的OOD补上

OOD,从表象上理解是用class来抽象和模拟事物之间的关系,实际上是借助接口与继承这种抽象机制来decouple(解耦合)代码,使得代码结构清晰易于维护。在实践中,大家发现有一些解耦合的方式经常出现,就把它们总结为Design Patterns (设计模式)。很多人在读设计模式这本书的时候会有一种“啊,原来这种写法叫做这个模式”的感觉——然而一本系统性的总结书籍是必须的,1大家总有没用过见过的模式,2设计模式给出了一个交流的基础,举例来说当你讨论一段代码的写法时的时候不用自己在组织内部发明一套语言,或者绕一个大圈子描述细节,而是可以简单地说,我们可以用xxx模式

学OOD,就两本书,一本是大名鼎鼎的Design Patterns: Elements of Reusable Object-Oriented Software,因为作者有四个所以又称GOF/四人帮

另外一本是Head First Design Patterns,相对来说浅显易懂

比较重要的常用的pattern只有:Factory, Singleton, Adapter, Composite, Observer(Listener), Template Method, Proxy, Visitor, Iterator. 如果是临阵抱佛脚的可以多多关注这几个pattern。State,Bridge和Strategy也可以大体看看。

具体的pattern这里就不去讨论了,大家静下心来看书就是。要达到的目标大体上是 1 能够回答,xxx模式如何实现的 2 为什么要使用xxx模式(其优点何在) 3 在什么场景下使用xxx模式。其实不单OOD,任何一项技术能够回答这三个问题,也就算是有一个big picture了。

下面说点关于OOD的闲话。

OOD刚刚被发明的时候,是被很多人认为是Silver Bullet的。大家觉得它从根本上解决了代码reuse(复用)的问题——低耦合高内聚的代码,使得代码的模块化、重复使用不再复杂,进而解决了软件界一直存在的重造轮子的问题——结果我们都看到了,软件界到今天也仍然在重造轮子。软件界没有银弹——OOD不是,SOA不是,PaaS不是,IaaS也不是。说点哲学的,软件的复杂是内秉的:因为人类的需求是基于人类的高阶逻辑的,而计算机至今能满足的是一阶逻辑演算,所以软件界在强AI出现之前不能解决软件的统一解决方案是非常正常的。

当然我们不能说OOD没有解决问题,它毕竟是一种proven technique,在代码层面解决代码的可维护性问题一直都是码农手中的得力工具。相比procedure,它提供了有力的抽象工具,能够使得代码不是一坨互相调用来调用去的函数,而是具有抽象的接口,各司其职;相比functional,OOD的代码可能会显得不够简洁,然而Object Oriented的形式使得它更加贴近人类的思维模式——functional编程虽然强大但至今不成主流,也就是因为这一点了。

另一方面,我这些年在软件业中发现新人普遍具有模式沉迷的问题。这是难免的,因为设计模式都是精炼的前人经验,确实有一些精妙之处。但是设计模式本身是提炼解决问题的方式,实际工作中千万不要用设计模式去解决并不存在的问题。当应用一个设计模式的时候,尤其是感觉到啊这个设计模式用在这里简直精妙的时候,就要警觉一点了。这时候必须谨慎地想清楚,为什么要用这种设计模式,使用这种模式是否多余。举例来说,在两种行为模式之间,是选择if else好,还是用strategy模式?在两个数据库实现之间切换,是否要用adapter模式?

(这样的问题其实并没有统一的答案,都是case by case分析的。)

另外滥用模式也逐渐成为了现在Java程序员的通病。比如用factory,不要直接new之类的已经成为了部分程序员的真理信条;搞个singleton到处用结果成了包了一层的全局变量这种更是比比皆是。一言以蔽之,为了模式而模式,认为使用了模式就提高了代码质量,都是误解。

那么跑题都跑到这里了,代码质量究竟是什么?我本人对代码大概有如下几个方面的要求(很多人也许有不同意见):
1. 可读性——代码即使以后不被改动,也是有人要读的,如果一段代码三个月后作者自己都不知道写的是个什么玩意,必然不合格
2. 易扩展型——注意,是易扩展型,而不是扩展性。因为扩展性可能是一个不存在的问题,我们不应该为未来不存在的扩展浪费过多的时间,但是如果能够把代码组织成很容易改写成具有扩展性的代码,就可以在开发速度和维护性上做出一个平衡了。
3. 难改动性——想了想没有想到太好的词。这里的意思是说,通过组织代码的结构,使得未来的人难以做出危害代码质量的改动。举个简单的例子,在某个初始化函数里面我们初始化了三个有关联的成员变量,里面还夹了一坨逻辑,这时候把它们extract成一个method,给它一个有意义的名字,这样可以i)使得原有的逻辑不会因为后面的改动被打散,而变得不可读;ii)在增加逻辑的时候,后人会被这个method的名字所约束,不会破坏contract。当然如果你的初始化代码是纯逻辑的话这也是一个加入unit test的理想位置。
4. 无重复性——如果说写代码的时候有什么必须遵守的铁律,这就是其中一条。任何形式的重复代码都是绝不可取的,必须改掉。
5. 最后再推荐一本书,叫做《Refactoring: Improving the Design of Existing Code》,这本书并不是用来面试的,而是讲如何提高代码质量,避免写出烂代码。作为一名合格的程序员,不可不察。

所以回到主题上来,OOD要用,很好,然而你先要权衡用与不用之间,究竟利弊如何。

评分

10

查看全部评分

hadoopG 发表于 2016-3-11 11:21:40 | 显示全部楼层
膜拜一下lz
回复 支持 反对

使用道具 举报

wrf91324 发表于 2016-3-17 14:01:10 | 显示全部楼层
这个太棒了!学习了!
回复 支持 反对

使用道具 举报

xli147 发表于 2016-3-18 00:26:23 | 显示全部楼层
One of the GOF is my professor of OOP class
回复 支持 反对

使用道具 举报

本版积分规则

请点这里访问我们的新网站:一亩三分地Instant.

Instant搜索更强大,不扣积分,内容组织的更好更整洁!目前仍在beta版本,努力完善中!反馈请点这里

关闭

一亩三分地推荐上一条 /5 下一条

手机版|小黑屋|一亩三分地论坛声明 ( 沪ICP备11015994号 )

custom counter

GMT+8, 2016-12-8 16:18

Powered by Discuz! X3

© 2001-2013 Comsenz Inc. Design By HUXTeam

快速回复 返回顶部 返回列表