摘要：简单整理了各种语言多态性的相关内容以及部分高级特性。
－－－－－－－－－－－－－－－－－－－－－－－－－ delphi－－－－－－－－－－－－－－－－－－－－－－－－－加overload
【虚基类】delphi不支持多继承，所以没有虚基类这一说。
【虚函数】父类的虚函数定义有两种方式：(1)procedure draw; virtual;(2)procedure draw; dynamic......
摘要：#!/usr/bin/python# -*- coding: cp936 -*-
################################## written by caocao ## caocao@eastday.com ## http://nethermit.yeah.net ##################################
import sysimport ......
一个体现Java接口及工厂模式优点的例子 随着模式概念的普及,了解模式与使用模式的程序员越来越多,很多人在学习模式的时候,都会有这样一种疑惑:“有必要搞得这么复杂吗?”.的确,因为教程的例子过于简单化（这样方便读者学习）,或者是作者选例子的时候并没有很好体现所讲模式的优点,很多情况下如果仅就其例子的问题来说,用模式是太复杂了.因此才导致这样的误解:“模式就是把简单的问题复杂化吗?”.当然不是,随着你开发实践的不断丰富,你终会发现模式强大威力,而且模式也并非贵族化的编程方式,它就是一些经过提炼了的解决问题的方法技巧.
通过学习模式,程序员开始告别过去准直线式的代码方式,模式开扩了我们的视野,强化了我们面向对象编程的思维方式.然而现在又出现了另一个普遍的问题,盲目应用模式.模式是问题的解决方案,先有问题才有模式,模式是依附于所要解决的问题的而生的.必须了解模式在很多情况下是以提高代码的复杂度为代价来增强灵活性.可复用性.如果在自已的代码中使用某一模式仅只提高了代码的复杂度,而其它方面收效甚微,或者某部份代码根本就不存在灵活性及高复用性的需求,那么我们就没有必要为使用模式而放弃更直观简单的代码写法.
一流的高手90%精力关注问题的解决方案,因为找到了好的解决方案,再写起代码会很轻松代码也简洁流畅,看这样的代码是一种享受与提高;二流的熟手90%精力关注代码实现,因为问题的解决方案并非最佳,实现的代码也会比较复杂;三流菜鸟记流水帐,90%精力在敲键盘,常常做了大半才发现行不通,回过头来再用90%的时间敲键盘,根本不会用到任何模式,写出来的代码的只有他自已才能看懂.做出来的软件也是支离破碎,做一丁点改动都要大费周折,而且你还不知道改动后会产生什么问题,大有住危房里的感觉.
在这里还是举一个滥用模式的例子吧.我曾参与过一个大集团公司ｏａ系统的第二期开发,开发沿用原有代码架构并增加新的功能模块.文档很少我读原代码时就被它程序里的代码转来转去搞得头大如斗,最后读懂了:原代码架构总体采用工厂模式,而且是最复杂的抽象工厂模式.它把所有模块类都通过工厂生成还工厂套工厂,并且每一个模块类都有一个接口,每个接口也只有一个模块现实类,因为涉及权限控制还用了代理(proxy)模式. 读懂代码后我开始嵌入代码,发现每新增一个类,都要到六个java文件中去增加相应代码,而在类中每增加一个方法,也要到它的接口等四个java文件中去增加相应代码.天呀！！！记得当时我的小姆指常会不听使唤,就是因为频繁的使用ctrl+c .ctrl+v,小姆指按着ctrl键给累的.整个项目组苦不堪言,真烦透了.项目结束后我回顾发现:代理模式用得还对（现在针对权限这类横向控制有aop编程这种新的解决办法了）但工厂模式在这里根本就是画蛇添足,不仅没有解决什么问题,反而增加代码复杂度与耦合性,降低了开发效率连维护难度都提高了....
下一页 摘要：以下是我的代码. 看了一个似乎是msdn上的文章..大致看了下, 很不幸....不知道是不是这文章作者太武断..还是真的.net翅膀还没长硬...(我的ｅ文很差，要是译错的地方，大家装做不知道就好了，给点面子哈．．．)上面说到:“如果想在control box (system) menu上添加新项, 用.net本身的代码是没有办法实现的.很幸运的,无论如何,用一点windowsapi可......
