物体
生物
高级生物
人,外星人
中国人,美国人,日本人|火星人,宇宙人,那美克星人
做A事用A1方法,有中国人各种特有属性,各种属性决定行为和方法|做V事用V2方法(美国人从来不做A事,也不从来不去思考A1方法),有美国人各种特有属性,各种属性决定行为和方法|..........如果以此类推的话,我们就根本没有办法在比较抽象的层次(比如 高级生物层)去定义接口.因为他们各种人的行为都是不同的.你无法定义一个抽象方法 A1. 因为这个方法 [美国人] 根本就无法实现,那就更别提外星人,外星人在生物构造上都和地球人不同 还别说行为准则.
那么.这就引发一个问题:这个模式下的 软件工程是否还可以[面向对象]?
如果答案是 : 抽象类 继承的话.
那么,我们常用的接口方法,多态,通过接口动态加载实现方法 等等均无法实现. 因为: A1方法 美国人根本不实现.那么,是否要细化设计呢?
比如 中国人 有中国人的抽象类 (甚至各省人都有各省人的抽象类),这个抽象类继承于实体类[人];[人]再继承于实体类[生物]...
这样的话,如果调用 I中国人.A1(); 的话 OO的思路得以实现了,实现A1方法的类都可以动态变更.
但新问题又来了.如果这样的话,那接口岂不是多如牛毛,在主调用的类里面充斥着大量的接口反射代码.这样的话相比面向过程式(设计巧妙的)编程还有优势吗? -- 或者说我们要半面向对象 ,半面向过程?
我还讲一个例子:
程序
通信程序
对通信做操作
发送,接收,处理消息这个例子直接单接口就可以实现. ICORE接口,下面挂3个方法,1-send;2-resv;3-process
我讲这个例子的目的是为了说明:这个规模的软件,用OO就是太合适了.然后我再发一个链接:
http://topic.csdn.net/u/20100331/14/6c00a5f8-d753-4407-9cc8-ce19af605588.html
有人说我是疯子,我不知道看了我这篇还有没人说我是疯子...
生物
高级生物
人,外星人
中国人,美国人,日本人|火星人,宇宙人,那美克星人
做A事用A1方法,有中国人各种特有属性,各种属性决定行为和方法|做V事用V2方法(美国人从来不做A事,也不从来不去思考A1方法),有美国人各种特有属性,各种属性决定行为和方法|..........如果以此类推的话,我们就根本没有办法在比较抽象的层次(比如 高级生物层)去定义接口.因为他们各种人的行为都是不同的.你无法定义一个抽象方法 A1. 因为这个方法 [美国人] 根本就无法实现,那就更别提外星人,外星人在生物构造上都和地球人不同 还别说行为准则.
那么.这就引发一个问题:这个模式下的 软件工程是否还可以[面向对象]?
如果答案是 : 抽象类 继承的话.
那么,我们常用的接口方法,多态,通过接口动态加载实现方法 等等均无法实现. 因为: A1方法 美国人根本不实现.那么,是否要细化设计呢?
比如 中国人 有中国人的抽象类 (甚至各省人都有各省人的抽象类),这个抽象类继承于实体类[人];[人]再继承于实体类[生物]...
这样的话,如果调用 I中国人.A1(); 的话 OO的思路得以实现了,实现A1方法的类都可以动态变更.
但新问题又来了.如果这样的话,那接口岂不是多如牛毛,在主调用的类里面充斥着大量的接口反射代码.这样的话相比面向过程式(设计巧妙的)编程还有优势吗? -- 或者说我们要半面向对象 ,半面向过程?
我还讲一个例子:
程序
通信程序
对通信做操作
发送,接收,处理消息这个例子直接单接口就可以实现. ICORE接口,下面挂3个方法,1-send;2-resv;3-process
我讲这个例子的目的是为了说明:这个规模的软件,用OO就是太合适了.然后我再发一个链接:
http://topic.csdn.net/u/20100331/14/6c00a5f8-d753-4407-9cc8-ce19af605588.html
有人说我是疯子,我不知道看了我这篇还有没人说我是疯子...
如果我是个UDP的服务器只要接收和处理 那我保留Isend有意义嘛??? 所谓抽象出他们相同的东西 而具体实现不同的事情. 对于 人这个例子 为什么我不会抽象一个 human父级抽象类 然后再单独定义一个 IA来适应不同的子级类?? 非要把IA也要看作是human的共性那??? 你这个不是抽象粒度 是你认知范围有限
你是否能够区分使用接口跟进行反射的区别呢？
使用接口:
ICORE ic = (ICORE)动态实现类; 然后在ic.接口方法
反射:
通过传递进来的 类名称 动态的创建 这个类的对象,当然,这个类的类型就是 之前已经知道的接口名称. 好像还可以不知道接口名称,连类型名都可以动态的获取(这个我没实践过)
多的不谈了,再谈 所谓 反射,接口方法,接口是否能继承于普通类,抽象类是否能继承于普通类 就陷入细节了.我意思是那个意思,硬抠言辞错误的话 其实还很多地方有问题,比如我上面本来说的是抽象类,我下面又说的是接口方法.这样抠就没意思了.我的意思是:按照 中国人,.... 各种人的不同,他们各有各的 方法,A1,B1,C1....
他们的方法都是 后续需要调用的.
因为 美国人根本不实现A1方法.所以 他就根本不能继承 生物/高级生物/人 这3个接口.因为不可能从 最上面的3个接口中定义出以后可能会用到得方法.所以就必须从 比较细微的单元开始设计. 比如:从 湖北省武汉市人 作为粒度的点开始设计 Ihubeiwuhanren
然后以此类推设计各种这样的接口.我的意思是这样的话接口数量就会很庞大.
我的意思是:迟早会有一种软件需求要违背OO基本理念:接口的数量不能太多(具体不能超过多少我没记住,也懒得去查.)
我的意思是:这样的OO还有必要吗?
估计你也只遇到过 我下面那个通信程序 里的 ISEND,IRESV,IPROCESS 这样复杂度的应用.
1-5 个接口,每个接口1-5个抽象方法.你以为任何应用都能照搬这个OO模型么?
我让你定义 IPeople ,让你定义IPeople里5个方法.但这有意义吗.在将来的应用里面.
你需要的绝对不可能是 仅仅
IPeople ip = (IPeople)中国人
ip.方法1;
ip.方法1;
ip.方法3;
ip.方法4;
ip.方法5;
这样傻瓜的应用.你很可能需要用到
中国人.专有方法1
...
中国人.专有方法n你这样还这么做IPeople这个接口?还有什么意义?
你的回答还是 没有回答到我 设问的本质:
1-5 个接口,每个接口1-5个抽象方法.
你以为任何应用都能照搬这个OO模型么?10个接口以内, 每个接口10个抽象方法以内(不够?那双倍如何?)
OO思路设置这么个门槛没错吧.但什么是应用?应用就是某种情况下 如你所说的:必须要实现某某方法的时候,在这个时候 我断言:你必定会违反上面的约束(10个接口以内, 每个接口10个抽象方法以内)如果违反这个原则,那么这样的OO是什么OO?
无语了.你1个问题1个问题先回答吧.
首先第1个问题:
1-5 个接口,每个接口1-5个抽象方法.
你以为任何应用都能照搬这个OO模型么?然后第2个问题:
如果无法实现,那么就会出现需要定义 100个接口的情况.
这样离谱的情况 你是继续去细分功能呢 还是做其他选择?
对第2个问题 我先说点我的观点:
这样的情况绝对有.
比如开发网络游戏.据我所知,现在的网络游戏都是比较硬编码的.也就是说 他们虽然有时候用了OO特性,也有抽象类C++实现的.
但他们很多都是硬编码的.绝对没有全面按照[面向对象]的思路去实现游戏服务器的世界.换个话来讲:如果一个网络游戏服务器的代码需要做完全的面向对象编程,那么我想,其接口可能可以人为的控制在10个以内.但其抽象类可能是相当恐怖的.所以,可能会有一种折中的 [半OO]式代码出现.
一个网络游戏的服务器如果抽象点讲不过就是 : 处理客户端 发过来的指令 而已.但是,这绝对不是几个接口和几个抽象类就能搞定的. -- 如果你要OO的话.相反,网络游戏世界里 可变化的代码相对比较少.所以较多的情况下里面的设计都是 面向过程 或者说采取了部分面向对象方式来进行.我没太多时间去整理自己的思维和发贴子的措辞.你们当中指正我的许多观点我本身就理解.
其实我的帖子也只是想交流意见.也只不过是想说明:有时候抽象出来 4-5个方法根本不管用. 因为这4-5个方法无法覆盖到我们的应用. 我们的应用可能是 1000个方法,而且这1000个方法都已经经过抽象提炼了.而我们不可能说为了1000个方法去创建100个接口.
LZ我觉得你的说法有点抬杠了。
不知道你想说什么。sp1234的意思是，脱离了具体问题空谈是没有意义的。任何程序都必须有硬编码。
没有具体的情境，谈不上良好的设计，也谈不上糟糕的设计。
只有通用的框架库才会对于设计极端饥渴。也只有内核、运算程序、模拟器/解释器，才会对性能极端饥渴。只有一些特定的软件，才会要求0缺陷。就是软件本身，也受到了人力成本、市场等等的制约。如同从绝对意义上说，太空材料比铝合金好，但是做一辆100000元的自行车却是决策的失败一样。至于折衷，本身也没有对错。只有你把不需要保留的舍去了，把应该保留的留下了，这样的折衷才是对的。相反，虽然也是“折衷”，但是比不折衷更糟。至于取舍什么，还是要具体情况具体分析。