ohmygodlzl

一直想干件事儿，就是把自己了解的软件开发领域的知识画成一张知识地图，找了好多资料，没有发现这事儿该如何做的指导方法，于是就一直搁浅了。前些天部门技术经理开会，讨论到开发人员成长路上的瓶颈和迷茫，颇有感触，又勾起了我画一张技术知识地图的想法。太完美的想法难于落地，所以我画图的时候本着不是全面深入的原则，而是直觉、第一反应，目的就是梳理一下貌似堆在一起的零散知识，归归类，归类方法和内容都是我自己的...

[u][i]这个系列是早前发布在部门wiki上的，引导组里的兄弟入门OOD，希望同样对刚刚走到OOD门前的同学有用。[/i][/u] 一直想跟同志们探讨一下面向对象设计（OOD）的原则问题，但因为自己理解有限，怕说不好误人子弟，一直就没开始。现在想做个尝试，从浅处说起，便于理解，也希望能对我们日常的开发起到帮助。 我们做软件开发，要做的事情无非就是：拿到一份需求，通过...

[u][i]这个系列是早前发布在部门wiki上的，引导组里的兄弟入门OOD，希望同样对刚刚走到OOD门前的同学有用。[/i][/u] 在探讨单一职责原则（SRP）时，我用黑体强调了一句话：[b]如果你接到一个需求后发现需要修改一个已经存在的类，那就要考虑一下是不是原来的设计不合理，没有把应该独立出来的职责分离出来。[/b]我说这话的依据就是开放封闭原则――[b]软件实体（类，模块，函...

[u][i]这个系列是早前发布在部门wiki上的，引导组里的兄弟入门OOD，希望同样对刚刚走到OOD门前的同学有用。[/i][/u] 在继续探讨OOD的设计原则之前，我想先就OOD本身和相关的一些概念做些澄清，概念清楚以后再来看OOD的设计原则和我们现在的代码可能会把握的更好一点。 看我们有些模块的代码，最大的一个感觉就是：我们在用面向对象的语言写面向过程的程序。好多代码...

[u][i]这个系列是早前发布在部门wiki上的，引导组里的兄弟入门OOD，希望同样对刚刚走到OOD门前的同学有用。 [/i][/u] 按照面向对象的观点，软件中的实体应该是对现实世界中实体（或者概念）的模拟，这种模拟包括名称、属性（状态）和职责。打个比方，在软件世界中定义"狗"这个对象，我们需要从现实世界寻找启发，定义如下：[img]http://dl.iteye.com/...

[u][i]这个系列是早前发布在部门wiki上的，引导组里的兄弟入门OOD，希望同样对刚刚走到OOD门前的同学有用。[/i][/u] 现实中的每个人都要承担各式各样的职责，这些职责通常是由他面对的"客户"所决定的，比如一个部门经理，面对老板他的职责是执行、汇报工作等，面对部门员工他的职责是分派任务，监控执行等，面对客户他的职责是了解需求、解答疑问等；如果回到家，面对老人他的职责是尽...

[u][i]这个系列是早前发布在部门wiki上的，引导组里的兄弟入门OOD，希望同样对刚刚走到OOD门前的同学有用。 [/i][/u] 在我们目前的开发模式下－－使用Spring面向接口编程，这个原则给我们的更多是思维方式上的指导。所以在这里只是简单介绍一下这个原则，不举我们系统中的例子说明了。 先解释一下"依赖"这个词的含义，在软件世界里，引用、继承、实现（reali...

[u][i]这个系列是早前发布在部门wiki上的，引导组里的兄弟入门OOD，希望同样对刚刚走到OOD门前的同学有用。 [/i][/u] 对这个原则，我的体会不深，主要是因为没有在实际项目中看到违背它的后果，不过作为Bob叔叔OOD基础原则的最后一个，还是要在这里介绍一下。这个原则的说明如下：[b]子类型必须能够替换掉他们的基类型。[/b] 听起来是一个很简单的描述，基于继...

[i]写给公司开发团队兄弟们的帖子，转到这里分享下。[/i]当初初次尝试Scrum，便即取得成效之后，感觉很兴奋，到处跟人讲Scrum的好处，“用了以后，腰不酸了，腿不疼了，上楼也有劲儿了”，恨不得呼吁门口卖包子的阿姨也来尝试一下，可以卖更多的包子。而眼看当下，Scrum有在公司生根发芽的趋势，好几个组在尝试实施或者已经实施，我反倒觉得有点不安，就像推荐朋友去看一场自己觉得好看的电影，等朋...