OOP/AD basic
本文是为了配合庄子的论文,做一些OO的基础知识普及工作。
当然,即使是OO基础知识,我也不一定有足够的资格来普及,主要目的还是为了相互学习,共同进步。因此,为了便于读者找出漏洞,进行批评和抨击,帮助我进步,我尽量使用朴实无华,简单易懂的语言。用咱老百姓自己的话,讲述老百姓自己的故事。
为了突出重点,加强效果,文中不免矫枉过正,提出一些片面极端的看法。
为了方便起见,我也把Procedure Oriented称为PO。
1.代码重用
评价一门语言的重要标准之一,就是代码重用程度。PO的代码重用主要有两种方式:(1) 模块重用 Module Reuse (2) 模板重用Template Reuse
模块重用。比如,一个 a 模块,b调用a,c也调用a。这时候,a就是重用的。这种情况比较简单,PO已经做得非常好了,OO这方面没有什么太大的超越。
模板重用。一个处理流程的整个步骤都是固定的,就是其中一些部分是变化的。比如,在那个Design Pattern帖子里面。
http://forum.iteye.com/viewtopic.php?p=82944
那个排序的例子里面,sort算法是重用的,comparator是变化的。这个时候,sort就是一个模板template,comparator属于模板template中的变量。
OO在模板重用这个方面具有超越PO的语法优势。PO一般用Callback Function Pointer实现模板重用,而OO的Class内置支持this指针,具有了携带额外信息的能力。
2.OOP只是一种语法现象
PO如果要达到OO的效果,则需要用Struct + callback function pointer来模拟实现。C的语法记不清楚了,下面的代码就是一个示意。
如果要实现ReverseComparator,那么相当麻烦。
可以看到,PO实现高级的模板重用,不是不能做到,而是做起来非常麻烦。而OO语法内在就支持这种高级的模板重用。另外,OO语法的继承,对代码重用也有良好的效果,不过,目前继承好像有成为反模式的趋势,我就不多说了。怎么方便怎么用,代码简单,才是硬道理。
3.OOAD = Modeling
我同意庄子对“OO哲学”的批判意见。
OO书籍,我的观点是,只有OOP的经典书籍才值得细细研读。
大部分OOAD的方法论书籍,都在描述大而空的例子,而不是关注具体需求。
说实话,我们大部分人在做应用软件,而不是系统软件。处理的是业务的复杂度,而不是算法的难度。而大部分的OOAD方法论书籍,也是面向应用软件的。
如何处理业务的复杂度?无他,但手熟尔,全凭着行业经验的积累。一个不熟悉某个业务领域的程序员,要在两方面下功夫:(1)努力学习业务领域的知识 (2)努力提高业务建模能力。
如何提高业务建模能力?无他,但模仿尔,全凭着大师的经典著作。如Dlee推荐的《数据建模资源手册》,Martin Fowler写的《分析模式》等。这两本书讲述的都是需求中常见的业务模型,如人员组织,财务税务,生产销售,人力资源,等。
经典建模书籍,不可能包括所有的工作中需要的模型。碰到这种情况,一方面要尽量搜寻现有的经典案例,一方面要获取经典模型中的精髓,类推,举一反三,
在我看来,OOAD就是要积累这些数据建模知识,而不是学UML,也不是学哲学。当然,这只是囿于我目前的眼界和地位。
我希望将来有一天,我也能够达到这样的崇高的地位,靠谈论OO哲学过日子,而不是靠OO建模过日子。那意味着,我已经进入了制定规则的Top 10%, 脱离了开发工作的第一线了。
现在以我的程度,就开始依靠大谈OO哲学思想来获利,相当于大跃进,脱离了现有生产力发展阶段的现实;是要遭到痛斥的,“你这个穷小子,想混进我们这个富人俱乐部,别做梦了。”
4.过程
个人偏见,我认为,OOA 就是 A for OOP,OOD就是D for OOP。分析设计的时候,即使不考虑具体实现细节,也至少要考虑到实现的可行性和难易程度。
CMM类的过程强调,分析设计的时候,千万不能考虑具体实现,一旦考虑了具体实现,不仅是乱了规矩,而且是落了下层。
相比于CMM,我有些倾向于XP的实现和分析设计交织的做法。
我表达过对“良好的设计从重构中产生”的怀疑。我觉得,重构不一定能够保证产生良好的设计,反而可能产生过度设计。这也许只是囿于个人眼界的偏见。这个问题在另外的帖子里面讨论过了,就不在此赘述。
我觉得比较好的过程是这样:
(1) UI 先行。先画出UI Mockup。对于Webapp来说,通常是HTML Prototype。
(2) 在此基础上,写出简单的用户操作手册。
(3) 一项项具体分析该系统实现中可能遇到的瓶颈,评估可行性,风险性,选择实现方案。
(4) 数据建模。
(5) 按照XP原则进入到开发阶段:测试先行,开发,重构,迭代,集成,迅速发布。这是目前我所知道的代码管理的最佳方案了。
本文是为了配合庄子的论文,做一些OO的基础知识普及工作。
当然,即使是OO基础知识,我也不一定有足够的资格来普及,主要目的还是为了相互学习,共同进步。因此,为了便于读者找出漏洞,进行批评和抨击,帮助我进步,我尽量使用朴实无华,简单易懂的语言。用咱老百姓自己的话,讲述老百姓自己的故事。
为了突出重点,加强效果,文中不免矫枉过正,提出一些片面极端的看法。
为了方便起见,我也把Procedure Oriented称为PO。
1.代码重用
评价一门语言的重要标准之一,就是代码重用程度。PO的代码重用主要有两种方式:(1) 模块重用 Module Reuse (2) 模板重用Template Reuse
模块重用。比如,一个 a 模块,b调用a,c也调用a。这时候,a就是重用的。这种情况比较简单,PO已经做得非常好了,OO这方面没有什么太大的超越。
模板重用。一个处理流程的整个步骤都是固定的,就是其中一些部分是变化的。比如,在那个Design Pattern帖子里面。
http://forum.iteye.com/viewtopic.php?p=82944
那个排序的例子里面,sort算法是重用的,comparator是变化的。这个时候,sort就是一个模板template,comparator属于模板template中的变量。
OO在模板重用这个方面具有超越PO的语法优势。PO一般用Callback Function Pointer实现模板重用,而OO的Class内置支持this指针,具有了携带额外信息的能力。
2.OOP只是一种语法现象
PO如果要达到OO的效果,则需要用Struct + callback function pointer来模拟实现。C的语法记不清楚了,下面的代码就是一个示意。
struct Comparator{
void * info;
int (*compare) (Runnable * this, Record a, Record b); // compare is a function pointer
// 注:具体的OO实现中,为了处理继承的多态,
//虚函数指针不是直接放在这里,而是放在一个虚函数表
};
….
void sort(Record[] records,Comparator * comparator){
for(int i =….){
for(int j=….){
if(comparator->compare(comparator, records[i] > records[j]) > 0)
// swap records[i] and records[j]
}
}
}
如果要实现ReverseComparator,那么相当麻烦。
int reverseCompare(Runnable * this, Record a, Record b){
Comparator* originalComparator = (Comparator *)this->info;
return – originalComparator->compare(this, a, b);
}
….
Comparator field1Comparator;
… set up field1Comparator
Comparator reverseComparator;
reverseComparator.info = &field1Comparator;
reverseComparator.compare = reverseCompare; // function pointer
sort(records, &reverseComparator); // reverse order
可以看到,PO实现高级的模板重用,不是不能做到,而是做起来非常麻烦。而OO语法内在就支持这种高级的模板重用。另外,OO语法的继承,对代码重用也有良好的效果,不过,目前继承好像有成为反模式的趋势,我就不多说了。怎么方便怎么用,代码简单,才是硬道理。
3.OOAD = Modeling
我同意庄子对“OO哲学”的批判意见。
OO书籍,我的观点是,只有OOP的经典书籍才值得细细研读。
大部分OOAD的方法论书籍,都在描述大而空的例子,而不是关注具体需求。
说实话,我们大部分人在做应用软件,而不是系统软件。处理的是业务的复杂度,而不是算法的难度。而大部分的OOAD方法论书籍,也是面向应用软件的。
如何处理业务的复杂度?无他,但手熟尔,全凭着行业经验的积累。一个不熟悉某个业务领域的程序员,要在两方面下功夫:(1)努力学习业务领域的知识 (2)努力提高业务建模能力。
如何提高业务建模能力?无他,但模仿尔,全凭着大师的经典著作。如Dlee推荐的《数据建模资源手册》,Martin Fowler写的《分析模式》等。这两本书讲述的都是需求中常见的业务模型,如人员组织,财务税务,生产销售,人力资源,等。
经典建模书籍,不可能包括所有的工作中需要的模型。碰到这种情况,一方面要尽量搜寻现有的经典案例,一方面要获取经典模型中的精髓,类推,举一反三,
在我看来,OOAD就是要积累这些数据建模知识,而不是学UML,也不是学哲学。当然,这只是囿于我目前的眼界和地位。
我希望将来有一天,我也能够达到这样的崇高的地位,靠谈论OO哲学过日子,而不是靠OO建模过日子。那意味着,我已经进入了制定规则的Top 10%, 脱离了开发工作的第一线了。
现在以我的程度,就开始依靠大谈OO哲学思想来获利,相当于大跃进,脱离了现有生产力发展阶段的现实;是要遭到痛斥的,“你这个穷小子,想混进我们这个富人俱乐部,别做梦了。”
4.过程
个人偏见,我认为,OOA 就是 A for OOP,OOD就是D for OOP。分析设计的时候,即使不考虑具体实现细节,也至少要考虑到实现的可行性和难易程度。
CMM类的过程强调,分析设计的时候,千万不能考虑具体实现,一旦考虑了具体实现,不仅是乱了规矩,而且是落了下层。
相比于CMM,我有些倾向于XP的实现和分析设计交织的做法。
我表达过对“良好的设计从重构中产生”的怀疑。我觉得,重构不一定能够保证产生良好的设计,反而可能产生过度设计。这也许只是囿于个人眼界的偏见。这个问题在另外的帖子里面讨论过了,就不在此赘述。
我觉得比较好的过程是这样:
(1) UI 先行。先画出UI Mockup。对于Webapp来说,通常是HTML Prototype。
(2) 在此基础上,写出简单的用户操作手册。
(3) 一项项具体分析该系统实现中可能遇到的瓶颈,评估可行性,风险性,选择实现方案。
(4) 数据建模。
(5) 按照XP原则进入到开发阶段:测试先行,开发,重构,迭代,集成,迅速发布。这是目前我所知道的代码管理的最佳方案了。