摘要:面向对象的编程思想已经深入到了当今软件开发的方方面面，而我们一直鼓吹的OO的最终目标是什么？或许说最终目标有些过头，那OO带来的最大好处是什么？我们张口而出：软件复用！ 真的是这样吗？ “Grady Booch：我一般不相信广告宣传。或许我是那种愤世嫉俗的人--世上不存在万能药！不带虚假的。正如前面提到过的，软件开发过去是、现在是、将来也仍然是很艰难的，并且我没有预见到任何事情能改变这一点。就对象而言，其广告宣传声称它会增加重用。是的，它确实如此，不过不是是以我们不曾经期望的方式，因为OO编程语言导致了设计模式的产生。结果，我们在与编程语言不相关的层面上看到了重用，也就是在设计本身这一层面。我们实现了对重用的承诺吗？是的，不过不是我们最初期望的那种方式--对许多技术来说，这都是不变的真理。” “Grady Booch：我对OO编程的目标从来就不是复用。相反，对我来说，对象提供了一种处理复杂性的方式。这个问题可以追溯到亚里士多德：您把这个世界视为过程还是对象？在OO兴起运动之前，编程以过程为中心--例如结构化设计方法。然而，系统已经到达了超越其处理能力的复杂性极点。有了对象，我们能够通过提升抽象级别来构建更大的、更复杂的系统--我认为，这才是面向对象编程运动的真正胜利。” “Grady Booch：我看到了诸如J2EE（Java 2平台）以及Microsoft的.NET等平台的成熟。虽然两个平台都会继续主宰中间件市场，但是它们只能逐渐地成熟。例如，人们将对其中任一个平台付出如此大的投资，以致他们无法承担这些平台发生根本变化。因此，我们将会看到一定程度的稳定--这对整个行业来讲是有利的，因为技术剧变会给公司带来极大压力和矛盾。 此外，如果让我预测未来，我预见面向方面编程（aspect oriented programming）的崛起。今天的大型软件系统和高性价比的系统包括数万个移动部分，因此我们倾向于从来不关闭它们。所以，面对随之而来的挑战就是如何在不关闭系统的前提下对系统进行改进变这样的系统而又不关闭它们，使之通过包容众多的利益相关人的解决方案来提供附加价值。同时还要利用众多风险投资者来增加价值，用以作为解决方案的一部分。利益相关人风险投资者可以是包括图形艺术家、网络人员、安全人员和业务专家。在这样的情况下，您不能把这个问题看成是传统的编程问题。事实上，您不再构建一个程序，而是在不断对 -- 程序是某个大型系统的可变部件，那些部件彼此相互关联的部件进行改变连接。在这种环境中，通过使用方面（aspect），您将基于横切（cross-cut）那些部分的线程来构建系统，让领域专家从那些特定视角"表达一个方面（aspect）"。我认为在接下来的两年左右，面向方面编程（aspect-oriented programming，AOP）将在测试、部署和业务规则方面取得成果。”  ...[阅读全文]

摘要:1、在一个单键的类实例中定义了一个Hashtable，然后采用多线程来对同一个此类实例的这个属性进行存取访问，程序运行之初是没有任何问题的，在多个线程中可以同步的访问到Hashtable的数据，但是程序运行过一段时间之后就会发现不能同步访问这个Hashtable，也就是说有的线程能读取到其中的数据，而有的线程则无法读取了。奇怪的问题，不知道哪位对于此类问题有过经验，还望指点一二。 这个问题的来源是：这个Hashtable中保存有接收自移动网关的消息数据，有两个线程来操作这个Hashtable，线程A负责读取移动网关的消息并填充这个Hashtable，线程B则负责将这个Hashtable中的数据读出来存入数据库。 2、在VS.NET中究竟什么时候才会去“执行”Web页面？        这个问题会比较模糊，场景是这样的，在我们在VS.NET环境中切换到Web页面设计模式的时候，会莫名其妙的触发Global.asax中的Application_Start事件，但是并不是完全这样，并且还有更奇怪的事件发生。我们了解如果你的页面嵌入了Frame，那么在你切换到设计模式的时候，VS.NET会自动加载这个ASPX页面（如果在其中的Page_Load中有代码就会被执行），但是这种情况下不一定每次都会执行Global.asax中的事件，有的时候会执行而有的时候则不会执行。更为奇怪的是，如果执行了Global.asax中的事件，那么在事件Application_Start中通过代码检测到此时的上下文环境为VS.NET而非Web。这种时而触发Application_Start事件，时而又不触发，弄得人也没辙了。        谁对此了解较深，不妨指点一二？...[阅读全文]

摘要:MDA应当说在早几年就被逐渐提出了，不过最近发展的势头越来越迅速，OMG组织（国际对象管理集团）也显然将其作为了新的发展方向。 这些年，计算机软件领域出现的名词多的有些让人应接不暇，但是寻究其本质都是为了一个目的：那就是人们始终相信，在软件开发领域存在着能真正解放人类从事的重复体力劳动的技术。MDA的出现同样是怀抱着这样的梦想：我们已经厌倦了没日没夜辛苦的Coding，我们已经受够了客户需求的频繁变化带给我们的痛苦，我们需要能站在更高的层次上审视我们的软件。 MDA实质上是基于UML标准的，UML的广泛使用为MDA技术的出现铺平了一些道路。经常使用UML来描绘并分析设计软件系统的人一定会有一些相同的感觉： 1、UML说到底不能十分精确的描述我们的软件系统，比如像建筑业图纸那样的描述系统 -- 而这正是我们要追求的目标。 2、在针对使用UML设计的系统进行实现的时候，越是到了项目后期，越是会发现我们的代码实现和最初的设计相差越远了。虽然现在有很多的提供了代码和设计同步的工具 -- 比如XDE,Together for VS/JB，但是他们出现的目的显然是：出现了问题而弥补问题。并不能从根本上来解决这个问题。 MDA的出现不能说是专门为了解决上面问题的，但也正是认识到了UML的局限性以及未来发展目标才有了MDA的概念。MDA的详细理论我想不能在此多谈什么（我也所知不深， ），我只是十分关注这个技术趋势，正如当初UML给我们带来的冲击一样，MDA的出现也会带给我们巨大的震撼 -- 虽然在最近6到10年内能否真正实现MDA的构想还是未知数，至少，我们有了一个努力的方向。 国外对于MDA的关注会比较早，也有了较多支持MDA技术的建模工具：1、Borland ECO(Enterprise Core Objects)?? ECO在C# Builder中可以看到，但是其实用性不是很强，但是只要Borland肯持续投入，我想我们对于Borland还都是很有信心的。2、ArcStyler?? 他提供了对于J2EE和.NET平台的MDA支持3、OptimalJ?? 也是一种优秀的MDA建模平台 当然还有很多，但是我在这里想要提到的是，在国内以及国外的几种产品对于“类MDA”开发思想的贡献，而我也正是在这些产品中看到了这类开发模式的震撼效果，的确是震撼的感觉，虽然这些开发模式会被一些纯理论研究的人归为“不是正路”。 首先是以色列的Magic系统工具/平台，他涵盖了分析、设计、开发、部署这几个最为关键的软件构建阶段，提供了快速的跨平台的软件生成功能，如果你的需求发生的变化，只需要几分钟（比如只是你的数据库Schema发生改动）的时间，它就会重建整个应用系统，并重新生成你需要的软件成品，的确是成品！并且你如果想要将基于.NET/Windows的产品转换为IBM AS400之上，你需要做的只是切换一下其“平台选项”，非常迅速的并且令人震惊的产生基于IBM AS400的代码，而前几分钟你看到的还是C#代码！ 同样出色的是来自乌拉圭的一个软件，Genux。他将整个软件开发过程通过自己的平台重新定义为：需求捕获、建模、自动化实现/部署这几个阶段，可以说和Magic的思路如出一辙。同Magic类似，他也是积累并沉淀了10几年才能有今天的成果（想想我们国内有些汗颜，不是汗颜我们无法做出类似的东西，而是汗颜我们能坚持如此之长吗？浮躁始终是国内软件业的最痛处）。Genux的开发速度到底有多快呢？一个复杂的饮料类厂商的ERP系统，2个业务专家（不懂编程语言），2-3个月内就完成实施上线了。你也许会想：不会弄上个垃圾系统吧，需求变化了怎么办？他们在给我们演示这套仅用了几个月就“开发”完成的系统时候，我们当场提出了一些苛刻要求，比如增加几个核心字段，在非常复杂的界面之上再让他们调整出来几个更为复杂的界面，本来的意愿是要难倒他们（因为我也不太信服这种开发模式），但是没成想几分钟即后，一切都如我们要求的那样完成了！ 另外一个产品就是国内的KCOM，他的思想也类似于上面两个软件，只是起步较晚，但是做的也非常的不错。 他们并不标榜自己是对MDA模式的一个实现（前两个的产生要远远早于MDA概念的提出），相反，他们都提出了自己的开发模式。但是用中国古语来说其实是“殊途同归”，甚至在目前来看他们做的要比MDA的当前实现还要好很多！但是，我认为如果要将一个优秀的崭新的开发模式在整个软件业推广开来，标准化是绝对需要的 -- 正如当然UML一同江湖那样，不能形成业界标准，再优秀的软件/模式都将会消失殆尽！ 上面我说了很多，其实就一个意思，不论是否是MDA模式，或者“类MDA模式”，他们所要达到的目的其实是一样的：让我们能在更高层次上审视整个软件构建过程！ 目前在公司正准备开发的一个基础平台会更多的借鉴MDA的思想，因为前一个版本其实就好像是一个多个组件的松散拼装，这次打算好好整合一下这个基于.NET的平台，能够涵盖开发、测试、部署三个阶段，至于设计（针对系统设计而非UI设计），我想暂时不会涉及到。...[阅读全文]

摘要:等了不少时间，终于收到了有货的提醒mail，第一时间上去定了一个，  ...[阅读全文]

摘要:这些天陆续看完了美国那个蒙面魔术师对于各种神秘魔术的揭秘，以前觉得非常神奇的幻术到现在才真正发现原来如此啊：大变活人、大象在你眼前的消失、一辆重型坦克的瞬间消失原来都是这样做到的。。。   于此同时，仿佛突然之间，Windows2000的核心源代码就开始在互联网上疯狂的传播，而它的不幸泄露的原因如同之前的半条命II和天堂II的源代码一样 -- 遭到了黑客的攻击，和此同命相怜的还有《魔兽世界》Alpha版本（幸好它泄露的只是成品而不是源代码）。   其实泄露的软件源代码就如同被揭秘之后的西方魔术，在告诉你之前，你或许对于魔术师如何将一个活人变消失非常好奇。当然源代码并不是魔术，但是在你得到源代码之前是会有非常大的好奇心的，仅从这一点上来说有一些相似之处的。 看着色彩缤纷的软件在你的机器上欢快而神奇的运行着，不正如在观看神奇的魔术表演吗？只是在有的时候，我们在充当观众的同时也扮演了魔术师的角色，向他人表演着自己的魔术，软件的源代码也就像魔术的奥秘一样成了我们这些“魔术师”最大的财富。正如魔术师不希望自己的奥秘被大众知晓，软件开发人员更加的不希望软件源代码被泄露。 就像每一个观看魔术表演的观众迫切的希望知晓魔术背后的奥秘一样，我们对于优秀的软件产品同样保持着对于源代码的这份好奇心。   但是你了解了魔术的真实内容并不意味着你就可以变化纷繁复杂的魔术/幻术了，只是意味着你有可能在某一个魔术师变魔术的时候，向朋友炫耀：我知道他的小把戏！但是对于黑客来说就不是这么简单了，他可以在魔术师准备展示压轴戏的时候给你来个釜底抽薪。不过虽然Windows被黑客关注的程度远远大于Linux（这在一定程度上也造成了仿佛Windows漏洞比Linux多很多的假象），但是我想此次事件应当是不会对于MS造成非常严重的打击，但是至少提醒了MS保护源代码的力度应当再加强才行。   随着这次Windows2000部分核心源代码的泄露，Windows不论愿意与否，都将成为一个部分开源的操作系统了，至少在Longhorn出来之前。正如泄露了魔术秘密的魔术师一样，微软也不得不正视这样的现实：必须对泄露出去的源代码作非常严格的Review，以便保证不会因为这些源代码而暴露出来大的安全漏洞。   对于我们软件工程师来说，源代码不能真正给我们什么，即便是你拥有了Windows的2000万行源代码，也不能依据此来实现中国的操作系统 --- 就如同现在风风火火的某某国产操作系统一样，任何一个行业的蓬勃发展都是数个相关事物的共同促进来完成的，单单有一个Copy别人的操作系统就能拯救整个软件行业？源代码能给我们的是可以借鉴的优秀编程思想和开发技巧，而这些其实也是最重要的。从源代码被敲进编辑器那一刻起，它就只是source code，停留在它之上是最宝贵的架构思想、编程思想。   其实从事软件行业的人们不正像亲身经历着一次魔术表演吗？只是这次我们不再是观众，也不再是魔术师，而是这场魔术表演的参与者。在软件行业停留的时间越久，就越来越发好像乘坐了魔术师手中的单程列车。这辆列车启程开始旅程的时候，涌上来大量的乘客，绝大多数乘客并不清楚自己上来的真正目的，只是听人说这辆列车能开往幸福的目的地，确切的说是开往淘金的目的地。真正列车行驶了很长一段时间之后，就会发现这辆列车的旅程的确很长远，途中有严寒、有冰冻，有危险、有饥饿，于是中途下车的人也越来越多，而留在这趟列车上面的人们也不禁望望外面越来越恶劣的情况忧心忡忡 -- 这是我们期望的目的地吗？下车的人们也会懊恼的发现自己手里的车票原来是单程车票。   站在云端的上帝--我们的魔术师--或许在默默注视着这辆似乎没有尽头的列车，看着上上下下的人们而默不作声 -- 远方是云开日出的奇妙世界，就在列车行驶的下一站。...[阅读全文]