Kanas.Net Blog

我也见过这样的人，在公司内也一直存在这样的问题，很多就是为了把用户的钱先弄过来，而并不考虑这样的系统会给用户造成什么样的不方便或者损失，这就是为什么我们的软件无法强大起来的原因，就是功利性太强了。我更希望自己的软件能够更完美的解决现实的问题，如果是我，我会选择去修补这个漏洞，同时还会考虑怎么使得下水道也发挥更大的作用。
或许，太完美不可能实现，但是做软件设计必须这样。但是如果环境不允许，我们是否该退缩呢？软件是需要精神，同时更需要责任。
欢迎探讨，qq:258326103

学习！受教了！

收藏了

@碧落
如果你需要包括VsExtension的话，你需要安装一下vs2005 sdk，否则会报告你说的这个错误。
另外，可能也缺_zxh.snk这个文件，你可以修改assembly properties，不要强名称或者换成你自己的强名称。

老大，报告错误:
无法找到文件“C:\Program Files\Visual Studio 2005 SDK\2007.02\VisualStudioIntegration\Common\Source\CSharp\RegistrationAttributes\CodeGeneratorRegistrationAttribute.cs”。它可能已被移动或删除。

很感兴趣，不知道能否跟一份
我用 VS2005
3x

sephil@163.com

出售蓝奇高级验证码识别引擎，可准确识别新浪动网淘宝CSDN等多种复杂验证码。

输出为一个标准DLL，可供VB,VC,Delphi,C#.NET,VB.NET,模拟精灵,按键精灵等多平台调用，调用方法简单，几行代码即可完成。独具特色的边缘检测字符分离、旋转倾斜纠正和通用字符匹配算法（无论字体和大小）， 使得该引擎对于像新浪、动网、淘宝、CSDN等多种验证码均有不错的识别率，是一款效果较为理想的验证码识别引擎。附详细的调用实例和代码注释等相关技术文档。

官方网站 - http://www.purejoy.cn/yzm_advocr
识别效果怎么样一试就知道 - DEMO下载 http://www.purejoy.cn/yzm_advocr/advocr.rar

呵呵 今天又看到这篇老帖子
我目前还比较倾向于dataaccess class+代码生成器的架构

http://www.cnblogs.com/coderlee/archive/2008/02/11/1066915.html

我写了一篇对多态和范型的感悟 可以来看看。。

感觉1.0 很不错，我的一个项目部分参考了你的代码，非常感谢。
可以参考一下2.0版的程序，我的email:xjbnet@tom.com

相见恨晚哈，我也想看一下2.0下的版本

很多人还是不懂OO的，我就是一个，哈哈！

@双鱼座
心里想看看你的看法, 结果碰见点事, 一直没上网, 今天才看见. 其实就是你要说的这些 :). 另外我觉得敢想也很重要, 因为每个人达到同一境界的修炼道路往往是不同的, 而我们参看的大师的经验往往是有其具体的成长环境, 他们是对的, 但是我们就是悟不了. 相反, 一些看似和大师的"教条"不同的道路, 也许反而在精髓上更接近正确的原则.

不过学习这个事, 真的是很难, 不是一句两句能说清的. 但是也很简单, 就象你说, 耐得住性子, 能够坚持下去, 找到自己的路, 一下子就快很多了. 这样, 借鉴别人经验时也需有一个比较, 他的路和我的路是否一样, 如果不一样, 路变了, 具体的方法应该如何调整, 才能更接近真意, 这都是需要考虑的.

说实话, 做实事也好, 做学问也好, 我真正感觉迷茫的, 还是那些最没有意义的问题: 我到底是干嘛地的? 想明白这个问题, 聪慧点也好, 像我一样愚鲁点也好, 困难与否, 或者在具体问题上比如OO到底是不是一个提高生产力的有效方法, 其实都是无所谓的事了, 反正都要实践, 反正都要学习, 其它都是旁枝末节了

终于又看到双鱼大哥的文章了，哈哈

----------------感慨完毕，发表意见-------------------
OO是什么？我不敢说我就什么都明白了，但我敢说这东西绝对不是教条！“要OO，你必须这样这样这样”，实际上自己就错了；为什么不说，“有了OO，你可以这样这样这样”，“要做到OO，你可以这样这样这样”？

我一直认为OO不是技术，而是一种方法论；它是一种“可以”帮助你更有效率的工作的方法，而不是工作制度……

就像很多人BS数据库，我听过这样一句话“哎哟～～你们还在写SQL啊，我们早不用了”，我彻底无语，这好比“哎哟，你们还在说中国话啊，我们早不说了”一样的无聊……为了完成工作，我们有很多方法，不是只有一种，究竟选那种是需要具体问题具体分析的，“某中方法就是比其他的好”这样的观点是站不住脚的

我看这篇文章有些深奥。正好是个学习机会。
你的源码，没有看到共享的地方，能否给我发一份，研究一下。
谢谢。

现在很多人似乎对模式的理解得错误了，模式只是一种做事的方法，而并不是评价做好一件事情的标准。我们做事情很多时候只是相似而不是对等，所以模式也必须根据当前情况进行调整和选用。同理OO是好但其本身只是一个指导思想，但对于其使用方式来源于自己的不断实践和积累而不是单一的理论指导。开发人员更注重的是代码重构而不只是关注模式的应用。

@彭成刚
或许你又把OO赶到了“适用场景”的死胡同？
@双鱼座
多谢谬赞！

@怪怪
可能是我的表达不够准确。不过你所谓的“耐着性子钻研”是有歧义的，有一种“耐着性子钻研”其实只是表面上的，实质是动机不纯、出发点不对。OO与否并不是教条，但一定会经历一些教条的过程，然后才能抛开教条。所以，我极其赞赏你提出的两个问题，很多人都在自己不恰当的程序下参与一些不恰当的讨论。这只是我说的“浮燥”的表征之一。
我想提醒大家的是：够不够OO，用了什么设计模式并不重要。OO说到底仅仅只是一种境界，靠悟而不是靠钻研。既然是靠悟，偶尔有几个一辈子未能得悟也是正常啊。我MSN上的签名是“恰恰用心时，恰恰无心用，无心恰恰用，常用恰恰无”(引自唐代一位禅师的偈语)。其实那些一辈子潜心于修禅之人，目标决不是为了悟，悟只是副产品而已。为悟而悟，终无所悟。此为真耐心也。
OO的精髓是一种思想，然后在此基础上一代代大师在挖掘、传播的过程中建立了一套理论，一套原则。要驭之，必先知之，后悟之。任何原则必须先掌握，认同，然后才有可能发现这些原则的局限。但是很多人却不是这样。一种情况是有人总是在掌握这些理论之前就被这些理论所困住，以教条来约束自己，引导大众。另一种情况是有人总是高估自己对这些理论掌握的程度，摇摇晃晃，成效不彰，只能无端生出些许抱怨来。
其实什么人什么时候适合尝试OO并没有一个统一的标准。我是5岁学会游泳，14岁才学会骑单车，至今还不会驾车。OO和游泳、骑单车、驾车一样，其研修的过程并没有统一的准则。所不同的是：如果有一点传播作为基础，悟的过程会快许多；而游泳、骑单车和驾车则纯粹靠悟。
以上浅见，与君共讨。

期待你的net2.0版本

非常有启发。
有效的设计是通过恰当的抽象提高内聚度，以及达到松耦合。OO只是达成这一设计目标的一个有效的武器而已，所以更重要的是进行设计的人的水平。像楼主这样把对word文件中的敏感数据位置的描述抽取出来放进一个XML文件中的作法就是具有良好编程思想的体现。相信楼主即使使用不支持OO的语言（例如C语言）也一样可以编写出高内聚度的程序。那么反过来我不禁要问，那些抵制OO的人，是否一直在追求使用面向过程的方法提高内聚度呢？我不否认有这样的人存在（他们应该是在信仰着什么），但我相信更多的人认为只要程序能跑起来就行了，只要这样就好了，反正不管用什么方法不都是每天工作8小时，而且1年后自己是不是还在这家公司还维不维护这个程序都说不定的。

就项目的开发来说分两种，一种是用对象，对象做好了已经，调用一下，或配置一下。。ok。。

还有就是开发这些对象。。

前者是不需要什么技术而言，只要有对象的配置文件说明就可以使用了。。
而后者需要大量的程序经验，并且不参加项目开发。

前者的效率快，速度快。。可以说是操作工。。
而后者是开发团队，速度慢，但是延展好。。

可是我们国内还是属于前者。。
你说你一个操作工想去学什么面向对象，可是看看你的工作是什么。。是操作工好不好。。
可是我们国内有开发团队的公司实在是太少了。。

就我个人想，就是一个很就经验的开发队员，如果每天都在2天一个项目的公司里呆着。估计也做不出什么好的“对象”吧。。

不知大家对我的意见有什么看法。。在下只是说出了自己的看法。。
用对象的人，只是去用而已，是不用去学的。。就像是你用windows，你会开发windows吗？我想你不会吧。

@双鱼座
"心急吃不得热豆腐，耐住性子比OO本身更重要。据我所知，抱怨OO的人绝大部分都有点心浮气燥。“抱怨”就是他们最典型的特征，所以别被他们的抱怨所影响。相信很快有一天你终会水到渠成、瓜熟蒂落，然后你再来评判我今天的结论，相信你会同意我。"

你这段话可有点太随意了..., 你看看园子里多少人搞不清楚MVP是什么MVC是什么, 设计模式怎么用的恰到好处; 多少人较真于贫血充血, 这个够不够OO那个够不够OO; 怎么样建模才合理也是吵来吵去. 这些不是抱怨, 不是心浮气躁, 恰恰是耐着性子去钻研后, 有了想法才出来讨论. 大家都说OO是前期投入大, 后期回报高, 无论是对项目还是对个人水平. 对项目, 如果已经有一批比较稳定不容易流动, 且水平不错的程序员, 我觉得这个说法有道理; 对于学习, 我觉很多人忽略了两个问题:

1. 自己或者某人适不适合当程序员. 很多人当程序员只是当一阵子, 未来无论是提升还是换行, 都不会一直做下去, 而自己未来如何, 他们自己都不知道; 而有些人呢, 毕竟二三十了, 思维方式已经固定了, 也不具备很好的消化知识的习惯和能力. 当个普通的Coder, 甚至未来升级成为某类项目的高级管理, 都很正常, 但是学习OO之类, 除了反而迷糊起来, 降低生产效率, 影响自己的职业发展, 没有任何好处.

2. 自己或某人当前水平下是不适合学习OO. OO的各种理论在一些人眼里归根结底就是那么几行话, 但对很多人来说是一个迷阵. 过早学习OO, 对这样的人来说不但不合理, 反而会因为错误的理解, 未来承担更大的代价.其实不光OO, 关于命令式编程中通过赋值保持状态, 这种看似最简单最基础的知识, 在谭浩强C这种书里可以说作为学习其它很多知识的前提条件的常识, 在国外计算机教学中, 是先学习还是后学习, 都有争论(见SICP).

你这种说法里面包括一个假设, 即学习OO一定是有益的, 然后自然而然得出结论, 如循序渐进将来一定能得到好结果. 教育和学习, 包括计算机教育和学习, 本身就是一门学问, 所以我觉得对于咱们这种不是搞计算机教育的, 回答新手问题的时候, 还是谨慎点好, 毕竟对可能造成影响的行为, 比如鼓励学习XX, 还是得有个责任感. 即使咱们是过来人, 毕竟具有一定水平不代表就一定能指导别人的学习路径.

其它的好坏不敢说, OO学习对人的已有基础要求比较高, 这就是它最失败的地方.

看到你另一个帖子的回复了，谢谢

@双鱼座
太感谢了，期待ing，看你和teddy发的帖子，俺都望尘莫及呀。想下载你们的源码好好琢磨琢磨

@双鱼座
双鱼，你的kanas.net有.net 2.0版本吗？能否学习一下。

@蛙蛙池塘
没有，其实MSDN就不错。
@辰
@小宇哥哥
很难苟同。个人觉得没有面向过程就面向对象或者面向对象就面向过程的说法。只有没有吃透面向对象的说法。面向对象不需要额外的成本。当然，学习的成本不能算。
@大傻
可能不是你想象的这样。“大程序”采用什么架构与“小程序”采用什么架构没有必须联系。如果你看了代码你可能会抱怨，为什么要引入那个名叫Global的贫血对象。其实这个对象仅仅只是一个参数传递器而已，用来适配不知道什么架构的“大程序”。
对于你来说一个Word文件也许一天时间足够，但对于我肯定不够(看出来了我要比你笨)，即便是完成了我也不能保证代码质量。我文章里讲了，我的方案的确可能比你花时间，但是我能保证代码质量，并且可以重用和扩展。这还不够本么？
@东风31
心急吃不得热豆腐，耐住性子比OO本身更重要。据我所知，抱怨OO的人绝大部分都有点心浮气燥。“抱怨”就是他们最典型的特征，所以别被他们的抱怨所影响。相信很快有一天你终会水到渠成、瓜熟蒂落，然后你再来评判我今天的结论，相信你会同意我。

@蛙蛙池塘
当然有，不过现在还不到正式发布的时候。如果你需要，请提供一个email地址，我把其中已完成部分的下载地址发给你。
Kanas.net Framework 2.0包含以下内容：
Kanas.net Data：持久层框架
Kanas.net Security：认证与授权框架
Kanas.net ObjectScape：数据集化框架
Kanas.net Web：Web支持框架
Kanas.net Addin：VS2005插件集合
目前还待开发：
VS2005 DSL支持
DLinq 提供器
待全部完成以后，我会专门写文章介绍，并提供源码下载。

OO真的这么神秘吗？曾经以为OO其实不复杂，现在看了讨论文章，越看越迷糊！

看了文章,觉的不错,在不同环境下,oo和过程并没有冲突的地方,适合的地方就用,不适合的地方就不用.看楼主的例子,我觉得并不是一个值得推崇的例子,因为你的程序只是一个大程序的部分.你的大程序用了oo,所以这部分也用了,要是纯粹为了导数据,按照楼主这个word我用过程的化,一天的时间足够了.因为我以前做过类似的导入,比楼主的还复杂,因为那些是工厂以前没有数据库,都用word和excel来纪录所有的数据.但是就是没有楼主代码的通用性.呵呵

经历了很多公司,都是这样,以至于让我思考:

小项目用面向对象是不是累赘;

面向对象是不是带来的成本与日后的维护性相比不够;

你好,你这个东西有.net 2.0版本吗?

不是什么时候都面向对象。

也不是什么时候都要ORM。

我觉得一些明显是表单操作就对象关系。

测试已通过

@双鱼座
谢谢双鱼,我再下载看看,对了,你那里有emit的入门帖子吗?给推荐一下.

mark一下,好久没看到双鱼兄的文章了.

@蛙蛙池塘
已修改，的确是路径有问题。我估计你修改的绝对路径可能不对，现在我采用相当路径了。
@henry
哈哈，一直瞎忙。
@阿多斯
谢谢关注。

还是相当同意博主的观点。
我的一个前部门经理就一直说，我一直主张，设计要面向对象，但开发一定要面向过程。
另外，“第一步解决最小的简单模型；第二步解决复合的常规模型；第三步解决扩展的推广模型”，也是和我相同的思维。当然主要原因是咱没法一下子直接、正面地搞定复杂问题。

好久没看老兄发文:)
看这文章受益了,我一直也在想OO真的是不是这么神秘?
不过自己还是一直坚信只要代码简洁就应该足够了(其实我们应该花更多的时间问一下自己完成功能的代码真的是够简洁的吗?).

@deerchao
@怪怪
一家之言而已，欢迎批评指正。
@蛙蛙池塘
感谢你的关注。非常抱歉你说的问题，回办公室立即查对。

LZ这个例子我觉得是正确应用OO的经典例子.., 顺理成章, 很流畅.

"所以真正掌握OO是要放弃一些固有的、不全面甚至不正确的观点的，这才是OO真正的难点".

这个从某一角度看没错, 另一角度看, 一些观点正不正确, 不是那么好衡量的. 你说罪不在OO, 这个我觉得确实没法评判, 但是OO确实也不咋地, 人掌握不了, 你说不能怪OO, 我觉得恰恰相反, 不能怪人. 东西是帮助人的, 眼镜不清楚你可以说眼镜质量不好, OO掌握困难, 却是人水平不足, 这个有点说不过去.

比如你能掌握, 那是你在OO的道路上走得比较远了; 但不能单方面的想, 既然我能掌握为什么他们掌握不了? 我觉得OO作为一个方法论产品, 确实质量比较糙, 只是由于其它方法论质量也都差不多, 所以暂时显不出OO差劲来. 更好的方法论产品没被生产出来, 我们这些使用者, 就只能灵活应变了.

双鱼，我下载了源码，单元测试过不去呀，报下面的错误，我已经把测试文档的路径改了呀
测试方法 Zxh.Cpb.ImportsTest.DocReaderTest.TestEnumerateDocElement 引发异常: System.Runtime.InteropServices.ExternalException: Cannot open storage. File Name is: H:\study\down\Zxh.Cpb.Imports\Zxh.Cpb.ImportsTest\广东省建设项目环境保护审批登记表.doc。
还有如下
测试方法 Zxh.Cpb.ImportsTest.DocReaderTest.TestWordDocReader 引发异常: System.IO.IOException: 文件“H:\study\down\Zxh.Cpb.Imports\Zxh.Cpb.ImportsTest\广东省建设项目环境保护审批登记表.doc”正由另一进程使用，因此该进程无法访问该文件。。

回来了，双鱼说的不错，举的这个例子也很好，有时候遇到问题的时候就去靠经验去想解决方案，根本没在意这个解决方案是面向过程还是面向对象的还是面向服务还是面向方面的，最终解决了就好了。

先去吃饭，回来再看双鱼叔叔的帖子

你用到了XML的看懂了。

@Nathan2008
纯粹作为数据载体的实体模型为贫血模型,充血就不好说了,根据老马的提法,他是认为实体应该带有业务逻辑,这个他称之为Rich Domain Object,充血模型照理说应该是指这个Rich Domain Object吧.

什么是充血，贫血？

了解如何抽象、如何多态、如何协作，属于术，此为学也；了解如何用OO去思考，去设计，此为道也。为学日益，为道日损.
-------------
怪不得那么热烈，你来我往，好不热闹, 原来还是没损到家.
但是却没人能验证有没人能损到家,因为损到家的人无为了,羽化成仙了,"有大美而不言了".

@双鱼座
无关开源 交流就很好了

谢谢指教，我下载你的代码学习学习看。

@mydotnet1999
想必是你没有下载我的源码。在.net环境下。Mixin还是一个遥远的梦想，所以动态代理是非常困难的。
我的解决方案的前提是：所有的属性获取方法必须调用基类的方法，这样当然就简单了。