您好!欢迎来到 南京典乐信息科技有限公司 ,江苏大型门户网站建设顶尖技术团队!
热点新闻
以合理的成本“注入”

首先要确定的是,“面向对象”仅仅是一个词。其次,面向对象的基础是“基于对象”。这就有两个要点:

1. 网状模型。

2. 在继承的基础上实现多态是面向对象的主要使用方式。

类比C的struct+函数指针或者回调函数,就能清楚地看到相同的做法不同的写法或者组织方法。

作为语言的设计者或者评价者,一种范式的好坏,关键看它如何鼓励用户,这种鼓励它好的效果是否超过坏的效果。赖到用户头上是毫无用处的。

我最喜欢举的一个例子就是bob大叔黄口白牙白纸黑字的写在书里的:他花了若干年才知道如何正确使用面向对象。何况“大众”呢?

@bmrxntfj
我的意思是做正确的事,而不是我们自以为“大牛”应该会去那么做的事 :)

你说的基本就是我表达的意思。但不仅仅局限于此。比如两个部件之间的交互,如果有明确的协议,就未必需要包装一层;比如一个方法接受一个对象,对这个对象提供什么应该有明确的定义。

对于后者,Linux内核里的结构体很多时候做的就相当的好;相反,一个从在框架内部组合出的对象,然后要求你用模板方法一类的模式去override以改变行为的设计很多时候却不那么直观。

对于后面这种面向对象的普遍做法,仔细分析就可以发现,它把一些知识点分散了。在C里你往往在传递前关心一下作为参数的对象的约束,而在面向对象语言里我们却是另找一块地方来做这个。

这本来也不是什么大问题,可由于我们可以更容易的创建各种构造的对象和对象模板(类),并不断的强调信息隐藏;每包装一次只复杂一点,最后传递的那个东西到底是什么就变得开始模糊了。

多说一句的是接口是一种对解决这种问题的尝试。但接口除了引入一堆繁文缛节以外,并不能从本质上改变什么;甚至进一步模糊了事物原来的样子,只是在预期的使用方式下看起来很美。

面向对象粉丝在这块的理由往往是,“接口后面的东西是可以替换的”。可关键在于我们不能认为每部分的绝对成本都因为其它部分隐藏到了接口后面而降低了,就认为总体成本降低了。事情总得人做。

如果是我们自己做,实际上这是一个朝三暮四的故事,最终复杂性要么在某处集中爆发,要么处处为难;如果是别人做,那个“别人”其实根本无法保证我们能“注入”或者至少以合理的成本“注入”。

自从面向对象大行其道以后,很多传统的手法被装裱一新拿了出来,他们从语言特性上来看更直观了;如果猛的一想,似乎也更有规矩了。事实上我倒觉得它更要求大家都是全知全能的神了。

那么怎么做才能避免白日飞升呢?更具体一点:

首先给复杂度画一根线,这根线要尽量的低,以自己初学编程时的水平为参考是个我个人觉得不错的建议。当然所谓的“复杂程度”,更多的是指和外部的交互性质,而不是指内在信息量。

其次,跨过这根线的,就看看有没有其他做法;如果找不到一个合理的做法,我个人断定它一定能继续分拆。

在比较复杂项目上,这样得到的结果,必然根本不够完成目标的,仅是一堆积木块而已。剩下的部分是如何组织它们的逻辑,在层次少和单一层次复杂度低之间选一个平衡做起来。

更多的,最后剩下的这一部分,如果能够继续形成基于已有积木块的库式风格,就继续走一遍相同的过程,然后再剩下一部分。

如此递归下去,最终剩下的那部分若再用些适合选定的语言、平台的方法论或者技巧把一切组织起来,就能使用的比较恰到好处,并且不会过于“坚固”。

这个意思不是说底层积木块内部就不可以使用复杂技巧,只有最上层才可以。更多的,我们可以把一个内部复杂的积木块看作一个独立的项目,对这个项目执行上述过程:这实际上是一个尺度问题。

只是:一个“内部复杂”的积木,若它不能有简单明确的外部交互,如上所述,这个积木就必须分拆。把交互作为组织层次放到更大的一个尺度上去。

另外我要重申的是,此文主要讨论的是风格和做法,不是说“不要费劲”或诸如此类。很显然的提取公因式之类的活儿是非干不可的了,是如何干,而不是该不该干的问题。

上一案例-赶贼网

Copyright @2011-2018 南京典乐信息科技有限公司 版权所有 全国联线:400-025-1949
南京市中华路420号江苏省高新技术创业园5层 项目经理:13851941123 QQ:260193150 点击这里给我发消息
本站关键词:南京网站建设 南京网站设计 南京随家仓网站制作 南京设计公司