相信自己

外卖汇

2008-09-01T21:18:00.000-07:00

http://www.waimaihui.comhttp://www.waimaihui.com/StaticAllStore.htmhttp://www.waimaihui.com/StaticAllAreaMark.htm

《.NET设计规范》——学习笔记(3) 命名规范

2007-10-10T18:23:00.001-07:00

一组一致的的命名约定对框架的可用性及其重要。名字要易于理解，同时必须传达每个元素的功能。大小写约定标识符的大小写规则 PascalCasing：如HtmlTag IOStream camelCasing：如htmlTag ioStream 要把PascalCasing用于由多个单词构成的名字空间、类型、以及成员的名字；要把camelCasing用于参数的名字。通用命名约定单词的选择对框架中标识符的名字来说，很重要的一点是一目了然。名字的意思清楚比长度短更重要。名字应该与场景、系统的逻辑组成或物理组成以及为人熟知的概念相对应，而不应该与技术或框架相对应。要为标识符选择易于阅读的名字；要更看重可读性，而不是更看重简短性；不要使用下划线、连字符以及其他任何既非字母也非数字的字符；不要使用匈牙利命名法；避免使用与广泛使用的编程语言的关键字有冲突的标识符

Adobe Flex 3最有趣的特征之一 :Web设计者和开发者的相遇

2007-09-20T23:25:00.001-07:00

著：Yakov Fain 译：叶进 Adobe将于2008年二月左右发布Flex 3.它有增加了一些新的改进和特色，尤其是它将使Flash设计者和Flex开发者结合在一起。CS3可以很容易的使Flex融入到Flash IDE的发布时间线上。Flash中的容器创建在Flex中将会得到足够多的发展。为了开发Flash CS3，你必须要有个一个Flex组件工具包。这就使得Flash艺术拥护者必须去学习至少一点点Flex的基础知识，那会使他们获得在接下来的几年中获得更多的市场。在今年的早些时候，我看到MS发布了Sliver流。我对这种可以被一个对于Web设计一窍不通的人开发的绚丽的GUI应用印象非常深刻。他（用时间线）创建了一个绚丽的画面，并且为Sillverlight开发者增加了添加他们自己写代码的地方。现在，Flash设计者也可以非常简单地就整合Flex为他们的作品添加代码了。

漫谈C#之关键字（1）

2007-09-20T02:10:00.001-07:00

每一种语言都有非常多的关键字，而且这些关键字也都大同小异，不过毕竟还是有些许的不一样。有些关键字大家碰到的多了，自然就熟悉了，但是有些关键字用得不大多，或者是新引入的，所以就不大熟悉了。我平常在用的时候，就是会碰到一些关键字，感觉有点生疏，平常也会把这些我不懂的关键字的用法了解一下并记录下来。想到应该也有很多跟我同样的人，所以就把我的记录跟大家分享一下。请各位tx多多指正！访问关键字 base：用于派生类中访问基类的成员调用基类上已被其他方法重写的方法 1 public override void GetInfo()2 {3 base.GetInfo(); // 调用基类上的GetInfo方法4 } 指定创建派生类实例时应用的基类构造函数 1 public MyDerived() : base() // 调用基类的构造函数2 {} 从静态方法中使用base

《.NET设计规范》——学习笔记（2.5）框架设计基础

2007-09-05T23:03:00.001-07:00

这篇文章在一定程度上是对前面几篇文章的一个总结。一个成功的通用框架必须是为广大具有不同的需求、技能和背景的开发人员而设计的。框架设计师面临的最大挑战是为这些多样化的用户群提供即简单又功能强大的框架。要设计即功能强大又易于使用的框架。80/20原则。要把精力集中在框架中使用最为频繁的部分（20%）要明确地为具有不同编程风格、需求、技能以及使用不同编程语言的开发人员设计框架。要了解哪些使用多语言框架的广大开发人员。我们往往会只为自己设计API，而没有清楚地考虑用户的真正需求。渐进框架针对不同的使用场景，为不同的开发团体提供不同的产品，这种多框架的方法在某种程度上说是成功的，比如MS有Visual Basic程序库，有Win32程序库，也有MFC和ATL，但它也存在严重的缺点：多框架使得使用某个框架的开发人员难以将他们的知识转移到下一个技能等级或使用场景（这通常需要另一个框架

《.NET设计规范》——学习笔记（2.4）分层架构原则

2007-09-05T01:51:00.001-07:00

分层设计使得在单个框架中同时提供强大的功能和易用性成为可能。考虑对框架进行分层，使高层API能提供最佳的开发效率，低层API能提供最强大的功能和最丰富的表现力。通俗地讲，象我这样的菜鸟只能用高层API，太低层都不懂，而牛人们都是想用也更愿意用低层API的强大功能的（个人意见）。ps：这边的高层跟低层不是指高深的意思。而是从易用性方面考虑的！避免把低层API和高层API混在同一名字空间中，如果低层API非常复杂的话（即包含了许多类型）。要确保单个特性域中不同的层能很好的集成在一起。

《.NET设计规范》——学习笔记（2.3）自说明对象原则

2007-09-04T22:07:00.001-07:00

在简单的使用场景中，一定要让框架无需文档就能使用。要确保API是直观的，无需查阅参考文档就能用于基本场景你总不希望写个“Hello World”都去查阅API文档吧。要为所有的API提供优秀的文档。一方面，并非所有的API都能自说明。不同的人会认为不同的API是自说明的；另一方面，有些人想在开始使用API之前完全理解它们。设计自说明API时最重要的一些考虑因素：命名要在规范检查中重视标识符名称的选择；不要担心标识符的名字太冗长；一眼就能看出相应的方法是做什么的，类型和参数是表示什么意思。而且类型的名字如果足够好，那么用到这些类型的代码会更易于立即和维护。要在设计过程的初期就让用户教育专家参与；考虑把最好的名字留给最常用的类型。异常要通过异常消息来清楚地告诉开发人员对框架的误用。强类型很明显，调用Customer.Name要比调用

做礼拜

2007-09-02T20:36:00.001-07:00

又是一周过去了，星期一又来了！早上，在公司里偷个空，写点东东：昨天是星期日：基督徒做礼拜的日子！自从呆子去年去了英国，也有一年多没见到她了。昨天我们越好见面的，还有冲哥和晓丹！昨天也是她要做礼拜的日子：她在英国受洗了！我以前也从来没有见识过基督教做礼拜的场景，所以跟呆子说，也想看看。我到富阳的时候他们的仪式已经开始了，我到的时候，上面是长老在做报告类似的，因为讲得是富阳话，我不大听得懂；不过这个很快也就结束了（大概是在我来之前已经讲了很久了:-P）。然后，他们就开始唱圣歌，唱了很多，我个人感觉那个旋律还不错，也很容易上口，也跟着唱了几首。圣歌中都是些赞颂耶稣，赞颂主的，也有一些是说希望主不要摒弃他们的，还有就是希望主收留他们。呆子，一直都在非常虔诚的唱，而且每次低头祷告的时候都非常虔诚（我作为外人，自然体会不到其中的滋味）。唱完圣歌，过后是讲了一段圣经上的内容，我们四个人，除了呆子，

《.NET设计规范》——学习笔记（2.2）低门栏原则

2007-09-02T18:58:00.001-07:00

框架必须以易于使用的方式来为普通用户提供一个低门栏。每个人在第一次接触一个新框架时，都希望其是简单而功能强大的。如果他一开始就感觉其很复杂，则会望而却步。要确保每个特性域的名字空间只包含哪些用于最常见场景的类型。应该把用于更高级的场景的类型放在子名字空间中。例如：System.Net命名空间提供了有关网络的主要API，而更高级的socket API则位于System.Net.Socket子命名空间。要为构造函数和方法提供简单的重载函数。参数少，且都是基本类型。不要在为主要的使用场景而设计类型中包含用于高级场景（这里我个人感觉是不常用的意思）的方法。通过从框架中减少（或至少不增加）特性，能够使开发人员更有效率。因为需要处理的概念减少了。CLR把多重继承排除在外就是这个原因。不要要求用户在最基本的场景中显示地实例化一个以上的类型。

《.NET设计规范》——学习笔记（2）框架设计的基本原则

2007-08-29T02:32:00.001-07:00

由于我怕文章的篇幅过长会使人看了头痛，所以，我打算分几篇文章把《.NET设计规范》第二章的学习笔记写出来，这样大家看着不至于太累！大概是接下去总共五篇文章是说“框架设计基础”的...... 对用户而言，真正的开发效率来自能够轻易地创造出非凡的产品，而并非来自能够轻易地创造垃圾。场景驱动设计的原则框架通常包含非常大的一组API。但在开发过程中，

《.NET设计规范》——学习笔记（1）

2007-08-27T23:11:00.001-07:00

第一章概述如果框架的设计者能够站在使用者背后解释应该如何使用框架，那么就不需要同规范了。精心设计的框架所具备的品质简单性在设计框架时，宁可不要某个特性比较复杂的设计，也不能破坏整体的简单性。设计代价高框架设计需要耗费大量的资源。框架设计应该是开发过程中明确而独立的一部分。精心设计的框架充满利弊权衡没有十全十美的东西。应该借鉴过去站在前人的肩膀上。要考虑未来的发展考虑将来发展框架是一把“双刃剑”。一方面，它以“万一”的名义增加复杂性；另一方面，它可以避免让设计随着时间的流逝而贬值，或避免产生无法向后兼容的设计。应具有良好的集成性一致性一致性是精心设计的框架的关键特征，它是影响开发效率的最重要因素之一。一致的框架可以是开发人员从框架中已了解的部分推知不了解的部分。一致性同时还可以帮助开发人员很快地认识到，设计的哪些部分是某个特定区域所独有的，

java垃圾收集算法(转)

2007-08-27T05:28:00.001-07:00

很长的一篇文章，不过看看应该有所助益！转自：java垃圾收集算法 1．垃圾收集算法的核心思想 Java语言建立了垃圾收集机制，用以跟踪正在使用的对象和发现并回收不再使用（引用）的对象。该机制可以有效防范动态内存分配中可能发生的两个危险：因内存垃圾过多而引发的内存耗尽，以及不恰当的内存释放所造成的内存非法引用。垃圾收集算法的核心思想是：对虚拟机可用内存空间，

接口和抽象类的定义方式举例说明(转)

2007-08-26T07:53:00.001-07:00

本位转自中国IT实验室原文地址：接口和抽象类的定义方式举例说明接口定义关于java的接口定义方式，以下三种情况下可以采用接口定义方式：1. 接口中声明的变量全部为final 和static类型的，并且这个接口的作用在于定义一些值不能改变的变量。举个例子：public interface ObjectConstants{public static final String SPACE = new String(" ");public static final char FORMFEED = '\f';}2. 接口中只定义可供实现的抽象方法EventListener.java public interface EventListener { public void handleEvent(Event evt); }Runnable.javapackage

如何获得数据库里所有表的名字（转）

2007-08-24T05:54:00.001-07:00

在CSDN上看到这篇文章，感觉很有用，不敢独享，转过来大家一起看看！平时我们操作比较多的都是表里的数据，也许突然有一天会需要把所有表的名字都列出来看一看——比如，你的论坛是按每个版块一个表来管理的，这时候你要在首页列出各版块的名字。应该怎么办呢？肯定得用SELECT吧……但我们平时使用SELECT操作的数据都是表里的数据，表的名字并不是表的数据，这可怎么办呢？ ...... 原文是用Ｃ#实现的，不过我感觉用其他的语言（比如Java）也是很简单的。下面是这篇文章的链接：如何获得数据库里所有表的名字