Delicate Arch不像其他景点，可以远远看看，然后开车慢慢靠近， 它后面是悬崖，要等你绕过一个石头山后，突然呈现在你眼前，象是对你走路1小时的报答。

在所有照片上点击，新窗口中出现的都是未压缩过的图片。

下面的大坑很象浴池，这个角度看，delicate arch 更像一个水龙头，呵呵。

这些图画上，人类显得太渺小了。

游客不少，印度人，欧洲人，东方人，我估计有的人来了一天了，就这样呆呆的看着巨大的delicate arch，沉思着。那个乌鸦倒是聪明，在这里供游客拍照，呵呵，当然有的游客是会给它些吃的东西，也不知道谁教它的。

回头看一下

delicate arch旁边，往下看，远处的石山

侧面看这巨大的手臂

远处

象很多人一样，我也躺在岩石上，觉得时间已经停滞了。

我和delicate arch

同事在吃汉堡，两只乌鸦顿时围了过来，只好随便“打发”它们一点了。

delicate arch旁

准备回去了，意犹未尽啊，但是必须走了，走出去要1小时，这里晚上可没路灯啊，今晚还要camping，需要找camping park之类的地方。

路上随便拍了几张

然后找到了camping的地方，提供水和电，厕所，浴室，很多房车也在这里，里面什么都有，外面还支着卫星天线。美国人生活真是惬意啊。

找到camping park后大家一起搭帐篷，呵呵，这是我第一次camping，没想到是在美国。

不一会就搭好了，然后去找地方吃饭。我们的行李什么的都放帐篷里了，美国生活很多年的同事说，放心，这里没人会偷你东西的，呵呵。

一顿不错的中餐，不管荤素，都是差不多10$，最后竟然把小费（10%算的，非常精确）都算进账单里，让我面面相觑了一番。

饭后在Moan走了走就回去了，突然发现竟然有满天的星斗！一闪一闪，大的小的，亮的暗的，真让人数不清的感觉。而且在那遥远的天际中，有一条飘逸宁静的长河——银河。我好像回到了童年，在院子里数星星，一个两个……

第二天往回开车了，又是一个好天气。

还是一路的奇峰怪石！

中途我们想去Aspen看一下，这是路边的一个房子，后面就是滑雪道，这种房子估计和海滩别墅一个价。就这个小镇，路上看到两个小飞机场！

山腰上的别墅，真会享受生活啊

回去的路上看到了彩虹，Utah之行结束啦！

好几天没更新博客了，这周有点忙。上周末，我们一行六人去了著名的Archs National Park！

早上7点从丹佛出发，开车要6小时到Utah Moab。途中有个非常纯净的湖，让我们的心情一下就放飞了。

途中都是些奇怪的山，完全没人雕琢过的痕迹，大自然之杰作！

看到后面山上没有，想象一下，冬天这就是滑雪道了，老美是很会享受生活的；这些山脚下都是别墅，价格肯定不便宜啊，冬天，只要出门就可以滑雪了，而且，科罗拉多州一年300多天晴天，冬天大雪封山，但是还是晴天啊，尽情玩，科罗拉多州是美国公认的户外运动圣地。

天是那么的纯净，白云也显得飘逸，路上的车都带着自行车，漂流的那种舟，今天我看了一下，大概300$一个舟，而这里的自行车非常贵，运动店里的都是200$以上的！

路上，看层次清朗的云就是一种享受！可想而知，如果东西在这风景如画的地方滑雪会是多么惬意啊！克州最负盛名的滑雪圣地，著名的富人区就是Aspen，阿汤哥都在这里有房子，冬天来滑雪，可见多好的一个享受生活的地方。

在这里开车可以飚的很快，路上车很少，路况又好，从科罗拉多州到犹他州竟然一个收费站都没有，一路开过去，对于爱开车的来说，是一种享受，但是一个注意的地方是，阳光太好了，开车要戴上太阳镜。

当你发现周围的山变成红色的时候，你就已经进入了犹他州。

巨石隆起的山峰，和岳麓山的感觉完全不同！这里只有石缝中的细草随风摇晃，仰视天空，朴质的石头沉闷的站立了千年。

终于到达！顺便提一下，这里的土地曾经都是私人的财产，后来都无偿捐献给国家了，但是条件之一为不可以用这些土地盈利！于是这公园的门票非常低，一般轿车，miniVan一车才10美元！都是论车的。而且一张票可以用一周时间，因为理论上要一周才能把全部景点游览完。实惠啊。

这个地理图显示，这里曾经是海底，地理上，随着各种地壳运动，分了很多层，沧海桑田啊，人类一生的100年，真是转瞬而过，既然是转瞬，为什么不让这回眸的瞬间露出永恒的笑容，让这瞬间的一刻充满欢乐，那些没事就爱生气、赌气，拿别人的错误折磨自己的人其实很傻。

第一个景点，一个浑然天成的巨石，已经让我们震撼了。

第二个景点，遥望的法老王，历史中的一段，孤独的法老，就这样遥望了千年。

很多人在这里拍照，这是一个突出的平台，从这里望去，好像在电影院第一排看电影的感觉。我觉得左边的手掌好像是竖起了中指，呵呵。中间高耸的象是个刷子，周围的象城墙，仁者见仁智者见智。

这里的山 和 云 都是放飞想象力的好地方！

合影一个，空间和时间的一点，用101010100记录了。

荒凉 让我们完全忘掉了工作，把我们完全还原到时间上的一点，空间中的一点，当你面对着自然耗费千年完成的杰作，第一感觉是人类真的很渺小。哪怕一个人再伟大，放到历史千万年的长河上，也只是一闪。

记得以前在讲西部牛仔的电影里看到过那些植物。是不是感觉云很立体？

balanced rock

蘑菇云

山神之拳

堆砌

巨人之脚掌

向最著名的Delicate Arch走去，估计一小时左右。

同样在巨石上行走，四周空旷，远处是悬崖，顿时有《加勒比海盗》里天之尽头的感觉。

有些感觉真的难以用语言表达。天之尽头。

山体的洞，千万年前，是某些海底生物的家园。

空旷，寂寥，体验自我和宇宙的关系。

看到远处山上的大坑没有

我爬到那里了，其实也不危险，石头的摩擦力很大，风把所有细沙都吹尽了，看似陡峭的山体，一点都不滑

从我所在的地方往下看，巨石之山，壮观啊！

终于远远的看到Delicate Arch，大自然的伟大杰作！

有人说象一个人穿一条松松垮垮的牛仔裤，我觉得象大地之神的胳膊和拳头，象征力量、坚强。

这篇太长了，分两部分，待续

原文来自：野蔷薇  http://www.yeqiangwei.com/club/f4b0l0fp1t342010p1.html 
PO:persistant object持久对象,可以看成是与数据库中的表相映射的java对象。最简单的PO就是对应数据库中某个表中的一条记录，多个记录可以用PO的集合。PO中应该不包含任何对数据库的操作.
VO:value object值对象。通常用于业务层之间的数据传递，和PO一样也是仅仅包含数据而已。但应是抽象出的业务对象,可以和表对应,也可以不,这根据业务的需要.个人觉得同DTO(数据传输对象),在web上传递.
DAO:data access object数据访问对象，此对象用于访问数据库。通常和PO结合使用，DAO中包含了各种数据库的操作方法。通过它的方法,结合PO对数据库进行相关的操作.
BO:business object业务对象,封装业务逻辑的java对象,通过调用DAO方法,结合PO,VO进行业务操作;
POJO:plain ordinary java object 简单无规则java对象,我个人觉得它和其他不是一个层面上的东西,VO和PO应该都属于它.
PO：
persistant object持久对象
最形象的理解就是一个PO就是数据库中的一条记录。
好处是可以把一条记录作为一个对象处理，可以方便的转为其它对象。
BO：
business object业务对象
主要作用是把业务逻辑封装为一个对象。这个对象可以包括一个或多个其它的对象。
比如一个简历，有教育经历、工作经历、社会 关系等等。
我们可以把教育经历对应一个PO，工作经历对应一个PO，社会 关系对应一个PO。
建立一个对应简历的BO对象处理简历，每个BO包含这些PO。
这样处理业务逻辑时，我们就可以针对BO去处理。
VO ：
value object值对象
ViewObject表现层对象
主要对应界面显示的数据对象。对于一个WEB页面，或者SWT、SWING的一个界面，用一个VO对象对应整个界面的值。
DTO ：
Data Transfer Object数据传输对象
主要用于远程调用等需要大量传输对象的地方。
比如我们一张表有100个字段，那么对应的PO就有100个属性。
但是我们界面上只要显示10个字段，
客户端用WEB service来获取数据，没有必要把整个PO对象传递到客户端，
这时我们就可以用只有这10个属性的DTO来传递结果到客户端，这样也不会暴露服务端表结构.到达客户端以后，如果用这个对象来对应界面显示，那此时它的身份就转为VO
POJO ：
plain ordinary java object 简单java对象
个人感觉POJO是最常见最多变的对象，是一个中间对象，也是我们最常打交道的对象。
一个POJO持久化以后就是PO
直接用它传递、传递过程中就是DTO
直接用来对应表示层就是VO
DAO：
data access object数据访问对象
这个大家最熟悉，和上面几个O区别最大，基本没有互相转化的可能性和必要.
主要用来封装对数据库的访问。通过它可以把POJO持久化为PO，用PO组装出来VO、DTO

通过美剧学美语，我觉得不错，但是下载到的字幕往往是这样的，不好阅读

1
00:00:41,622 --> 00:00:45,820
<i>Year after year, 20-something</i>
<i>women come to New York City...</i>

2
00:00:45,993 --> 00:00:48,826
<i>... in search of the two L 's:</i>

3
00:00:48,996 --> 00:00:52,193
<i>Labels and love.</i>

4
00:00:55,068 --> 00:00:57,229
- Yeah.
- It's the best.

5
00:00:58,372 --> 00:01:00,431
Hot dress!

6
00:01:00,841 --> 00:01:03,935
<i>Twenty years ago, I was one of them.</i>

7
00:01:15,055 --> 00:01:20,152
<i>Having gotten the knack for labels early,</i>
<i>I concentrated on my search for love.</i>

其实通过正则表达式可以很简单的解决这个问题！首先找一个支持正则表达式的字处理软件，比如KWrite！

查找   .+-->.+\n   ，用空白 替换所有

查找    \d+\n  ，用空白 替换所有 ， 还有 <.>  和 </.>

就可以了：

Year after year, 20-something

women come to New York City...

... in search of the two L 's:

Labels and love.

- Yeah.

- It's the best.

Hot dress!

Twenty years ago, I was one of them.

Having gotten the knack for labels early,

I concentrated on my search for love.

Turns out, a knockoff is not as easy to spot

when it comes to love.

What? You're married?

When you spend a lot of time in front of your computer, the annoying beeps start to drive you mad after a while. I really don't need to be told that I hit the wrong key anymore, so I've compiled a list of how to turn off all the system beeps in Windows XP.

One of the most irritating beeps happens when you use the Volume control… but there are other beeps, such as on error dialogs or when you hit the wrong key.

Disable Beep in Device Manager

Open up Device Manager by right-clicking on Computer and choosing Properties, then on the Hardware tab you'll find the button for Device Manager.

Select View \ Show hidden devices from the menu.

Find Non-Plug and Play Drivers in the list, and then right-click on "Beep" and disable it:

When it prompts you to reboot, select no, and then right-click again and choose Properties this time. On the Driver tab, change the Startup type to "Disabled" and then click the "Stop" button if you are able to.

This should disable the system beep speaker, but it probably won't change the volume control beep, so continue on.

Disabling Beep in Registry

Open up regedit.exe through the run box, and then navigate down to the following key:

HKEY_CURRENT_USER\Control Panel\Sound

Find the "Beep" key on the right-hand side and change the value to "no".

Disable Beep in Sounds Panel

Open up Control Panel and find the Sounds and Audio Devices panel, choose the Sounds tab and then find "Default Beep" in the list.

Change the sound drop-down on the bottom to "None" and then click Apply. This should disable the volume control beep.

You'll want to also change Critical Stop to "None" as well, and should probably also turn off some of the other items.

You can also use TweakUI to get rid of some of the beeps, but if you follow the items on this page you shouldn't need that.

今天去boulder玩，是一个著名的富人区，离downtown很远，旁边群山中，有一个山顶叫royal arch，先到网上查了一下，原来和Windows的一个壁纸很象：

在路上，可以看到远处的落基山

下车了，看到这山势，想起了“山色空蒙雨亦奇”，呵呵

山真的很美！旁边就是著名的富人区，每天都可以看到这雄伟的山，房子能不贵？

出发了，今天风挺大的

山路上，不像岳麓山，这里很多松树，没有樟树了 呵呵。

远处的boulder

终于看到了，royal arch！ 奇

远望

我徒手攀岩，有心爬到岩石顶，爬了一半，已经很险了，如果鞋滑一下，我都可能摔下岩石，我也不知道哪里来的勇气，竟想爬上去，但是同事们都劝我还是下来吧，万一出事就麻烦了，这不是在中国啊。我还是下来了，毕竟安全第一吧。我想起来那次在湘西，也是徒手上留着水的峭壁，只有一根铁链，我拉着链子一路爬上峭壁，中间有几次惊险，还好我拉的死，没有摔下去。惊险的经历总是记得很牢。

下山时，看到了一群鹿，环境保护的不错啊，而且不象岳麓山，山路上几步一个垃圾桶，这里少的多。

这种黄绿色的树，不知道是什么树，非常鲜艳

下山时已经晴天了。

回去的路上，远处的建筑是一个市区活动中心

周日了，美国同事请我们去BBQ，也就是烧烤，他是个年轻人，单身，住在downtown的公寓楼里，有些年轻人还是热衷于住在downtown的，去哪里玩都方便，上班也方便，他们的想法是等一结婚，把downtown的房子一卖，去买周边的house或者连排别墅过日子。

下面是downtown的风光。周末的白天downtown没什么人。

图中是一个美国老黄牛，一手拿着票——卖票，一手拿着求购票的牌子——买票！看到我拍他，估计是觉得丢脸，走了。

我们是先去还车，再去同事家，在租车点看到了这个跑车

悍马，同事租过，太费油了。

远处的教堂，在高楼中不太协调，下面有很多人。

丹佛的阳光非常好，天空总是湛蓝湛蓝的。

远处蓝色的楼，就是那栋公寓楼

路边的小店

烧烤开始了，其实和我们以前在长沙公园的烧烤是不同的，烤炉是用电的，所有肉都是超市买的，不用切，直接铺上去，把烤炉的盖子一盖就行了。

沉重的话题开始了

一个久居美国的华人告诉我，下面这些老铁轨，就是19世纪华工修筑的！这条贯穿美国东西的铁路，被成为“每一根枕木下都埋着一个华工的尸骨，每一颗道钉上都沾满了华工的血汗”。

网上查到下面的资料：

---

在我们满怀喜悦的心情欢庆“五一”国际劳动节之际，你可曾想到137年前的1869年5月10日，既是美国历史上具有划时代意义的时刻，也是显示国际劳动者团结合作排除万难创造历史的伟大时刻。那是一个国际劳动者的盛大节日，一个原汁原味的劳动人民的节日。就在这一天，第一条横贯北美大陆的中央太平洋铁路和联合太平洋铁路提前完工，中国华工和美国各族人民一起，经过连续七年协同努力艰苦奋战,两支铁路大军在犹他准州奥格登地区的普罗蒙特里丘陵处接轨，其中承担最艰巨任务的西段主力正是特别能吃苦和具有聪明才智的华工。这一壮举宣告了美国大陆在经济运行上开始连成一片，标志着美国经济进入狂飙发展时期，美国行将成为面向两大洋的经济大国，也充分显示了中国的最初移民潮，对美国经济的发展尤其是加利福尼亚等西部地区的崛起，并对国际劳动者做出了杰出贡献。
---

原来五月一日劳动节，是庆祝美国两段铁路联通时形成的节日！

看到那些铁路，我仿佛看到了一个个骨瘦嶙峋，留着大辫子的华人，扛着一块黑黑的枕木，艰难的步行在落基山脉的峡谷中，仿佛听到了洋人的辱骂看到了挥舞的皮鞭，仿佛听到了无奈的叹息和婴儿的哭泣，那一个个瘦弱的身影，忙碌在嘈杂的工地上，他们的眼神里会不会有些希望，他们的泪水里是不是透着坚强？

一百多年过去了，我站在铁路旁边高高的现代化公寓楼中，望着伸向天际的铁轨，思绪却定格了，我只有一个想法，要想在外国受到尊重，只有一条路——国家强盛！

国家强盛，中华复兴！这是百年来华人的梦想！更是那枕木下冤魂的救赎！

下面的图片来自网络，当年华工劳动场面

内华达山上树立的华工纪念碑

陈列在华工博物馆里的算盘

远处就是轻轨站。

楼顶可以烧烤，还有个游泳池

很多老美游泳后躺在长椅上晒太阳，有点晒的通红，蜕皮

这个公寓楼，进门，使用电梯，出楼道门，都要刷卡。

我们住的地方

回来后先打会台球吧。

to be continued...

    今天去了castle rock和macys，castle rock是outlets，厂家专门店，比较大，比较便宜，梅西是百货，比较高档的地方。

后来去了apple专卖店，呵呵

卖场上面的饭店，各色小吃

吃了饭就去超市

透过车窗拍的，呵呵

韩国人开的亚洲超市，卖我们常吃的青菜。

今天买的鞋和T恤，Columbia和Levis，旁边还有超市旁边免费拿的报纸，竟然有+大+纪元+呵呵，很反动~

    今天出去真累了，明天下午eric请我们到他家bbq烧烤，上午可以好好休息一下了。周一又要上班了。

看看我们旅馆旁边的美国小区，非常让人羡慕。

对面就是我们的旅馆

我们周末租的车，Ford，租金汽油由公司paid。其实周末也去不了哪里，也许只有购物吧。

回来后喝咖啡，哈哈

顺便看看电视，正在播 泰坦尼克，经典啊，看得我好想念念。

to be continued...

    上班的轻轨站一角

天桥上

上班路上

美国中产阶级的房子，真的爽

小区的绿化很好

我们住的地方

晚餐，比较清谈，我把这次来美国看做减肥之旅。呵呵。

在租车的地方，拿了很多广告，地图等等。注意到outlets没有，是厂家直销的地方，东西便宜。

科罗拉多地图，左边的部分就是落基山。

轻轨 路线图

上班高峰，就这么几个人等车，一路上都有空位。

公司附近

天空很蓝吧

车站，火车，轻轨，公共汽车全在里面

公司的写字楼——1899 wynkoop

google地图上的A点就是公司了。

    到目前为止，感觉有的美国人有点懒，有点得过且过，工作和生活分的很开，注重生活的乐趣和质量，工作狂被认为是呆子。轻轨上，绝大部分人不户呆坐，有个看书，有的摆弄手机，有的mp4。公司里不错，喝不完的咖啡，用不完的各种咖啡伴侣，各种茶叶等等。墙上还有几个通知，有个是说公司里性骚扰是违背法律的。

    今天开会，一个黑人，一个印度人，三个白人，我一个华人，真是人种聚会啊。印度阿三们的英语我基本听不懂的，美国人基本可以知道他们在说什么，但是也并不确定，中国人发音普遍标准，就是词汇量太少了，需要和老外据理力争的时候，词汇量往往捉襟见肘。中国人和阿三都感觉自己是外人吧，比较谨慎的，老美们开会非常轻松，工作没有什么压力，下了班自己的生活才刚刚开始，怎么能在上班时间把精力耗尽？当做软件变成象体力活一样麻烦，让人费心的时候，外包给中国印度是不可避免的。美国有很多中年的工程师，大概45-50左右，他们是研究和开发的中坚力量，而中国，基本没有这样的工程师，都让大革命给耽误了。

    最近有两党的大会，我看了一会共和党的代表大会，虽然气氛比较热闹，感觉挺人性，但是怎么看怎么象中国的春晚，因为台上的人一说话，下面的就有人带头鼓掌了，台上的人还总爱幽他一默，类似单口相声。

    美国并不像美剧里那样，漂亮的人那么多，丑的多极了，呵呵，各种各样的怪样子，肥胖，偶尔一个白人美女可以让你眼前一亮！

    其实感觉电视台直播的党代会，非常作秀，说的也都很空，就象同事描述的，和公司的年度季度会议一样。

to be continued...

    下了飞机，有车接我们，呵呵，沿途拍了拍公路的风光。

    据说丹佛在美国也算是环境好的地方了，空气非常净，天空非常蓝，旁边就是Rocky Mountains落基山。

    车直接把我们带到了旅馆——类似国内的度假村，3层的公寓，2个客房共享一个厨房和客厅，前一阵子民主党大会也住这里，呵呵。

    周一到的，所以晚上8点正在播放越狱第四季第二集。美国的电视基本上全部可以调出字幕来，方便英语有障碍的人，从新闻，广告到电视剧都有字幕，脱口秀的字幕是当场有人敲的，电视剧是提前敲好的。

冰箱，烤箱，灶台，洗碗机，微波炉，咖啡机。只有菜刀是自己带去的，美国的刀太难用了。

我的床，够大吧

卧室

放下东西，马上奔向supermarket，去了沃尔玛和韩亚龙

    蔬菜可就贵了，大白菜，小白菜，包头菜，西蓝花最便宜，不超过一美元一斤，全瘦猪肉2美元左右，和国内一样。大米和国内的泰国米一样贵，还好我们只有吃饭自己花钱，轻轨，租车，手机，住宿还好都是公司付钱，否则活不成的。

    丹佛的人少，才50多万，是杭州一个零头，大超市里，据说周末也基本没什么人，更不用说象杭州超市那样排队了。

to be continued...

http://www.cnblogs.com/wxf0701/archive/2008/05/20/1203209.html

使用指向基类（超类）的引用的函数，必须能够在不知道具体派生类（子类）对象类型的情况下使用它们。
　　[ Function Thar Use Referennces To Base(Super) Classes Must Be Able To Use Objects
　　Of Derived(Sub) Classes Without Knowing It ]
　　Liskov替换法则
　　1.显而易见，Liskov替换法则（LSP）是根据我所熟知的"多态"而得出的。
　　2.例如：
　　方法drawShape应该可与Sharp超类的任何子类一起工作（或者，若Sharp为Java接口，则该方法可与任何实现了Sharp接口的类一起工作）
　　但是当我们在实现子类时必须要谨慎对待，以确保我们不会无意中违背了LSP。
　　3.若一个函数未能满足LSP，那么可能是因为它显式地引用了超类的一些或所有子类。这样的函数也违背了OCP，因为当我们创建一个新的子类时，会不得不进行代码的修改。
　　LSP示例
　　1. 考虑下面Rectangle类：

　　2.现在，Square类会如何呢？显然，一个正方形是一个四边形，因此Square类应该从Rectangle类派生而来，对否？让我们看一看！
　　3.观察可得：
　　a.正方形不需要将高和宽都作为属性，但是总之它将继承自Rectangle。因此，每一个Square对象会浪费一点内存，但这并不是一个主要问题。
　　b.继承而来的setWidth()和setHeight()方法对于Square而言并非真正地适合，因为一个正方形的高和宽是相同。因此我们将需要重写setWidth()和setHeight()方法。不得不重写这些简单的方法有可能是一种不恰当的继承使用方式。
　　3.Square类如下：

　　4. 看起来都还不错。但是让我们检验一下！


　　5. 测试程序输出：

　　6.看上去好像我们违背了LSP！
　　7.这里的问题出在哪里呢？编写testLsp()方法的程序员做了一个合理的假设，即改变Rectangle的宽而保持它的高不变。

    即 square 的 pre-condition 有， 改变宽度 或者 高度 ，那么 高度 或者 宽度 随之变化。

    而Rectangle没有这限制，那么子类增加了pre-condition，于是不满足LSP

　　8.在将一个Square对象传递给这样一个方法时产生了问题，显然是违背了LSP
　　9.Square和Rectangle类是相互一致和合法的。尽管程序员对基类作了合理的假设，但其所编写的方法仍然会导致设计模型的失败。
　　10.不能孤立地去看待解决方案，必须根据设计用户所做的合理假设来看待它们。
　　11. 一个数学意义上的正方形可能是一个四边形，但是一个Square对象不是一个Rectangle对象，因为一个Square对象的行为与一个Rectangle对象的行为是不一致的！
　　12.从行为上来说，一个Square不是一个Rectangle！一个Square对象与一个Rectangle对象之间不具有多态的特征。
　　总结
　　1.Liskov替换法则（LSP）清楚地表明了ISA关系全部都是与行为有关的。
　　2.为了保持LSP（并与开放－封闭法则一起），所有子类必须符合使用基类的client所期望的行为。
　　3.一个子类型不得具有比基类型（base type）更多的限制，可能这对于基类型来说是合法的，但是可能会因为违背子类型的其中一个额外限制，从而违背了LSP！
　　4.LSP保证一个子类总是能够被用在其基类可以出现的地方！

Overview

Design by Contract is a useful tool for thinking about and describing software. It can be used at higher level design and all the way down to detailed implementation. It can guide your specification, your programing, and your testing. Best of all, you can get these benefits with just three additions to your javadocs: pre-conditions, post-conditions, and class invariants. These three elements provide a checklist which you can use methodically to guide the development of software.

The Vida project has defined three additional tags for our javadocs:

• @pre for pre-conditions,
• @post for post-conditions, and
• @inv for class invariants

Think of a method call as a business contract. Pre-conditions are what the caller must provide to the called method in order for the called method to work. Post-conditions are what the called method must produce if the pre-conditions have been fulfilled. Class invariants are the working conditions: they describe the stable class instance in which the called method will do its work.

The Design by Contract javadoc practice is an extremely useful enhancement for
standard javadoc practice. Basic javadocs should still be written.

pre-conditions

The pre-conditions are part of a contract on methods. (In this article, constructors count as methods.) The pre-conditions list, one by one, the things that must be true for the method to succeed. For example:

/** 

* GOOD EXAMPLE:  

* Compute square root.  

* @param square  

* @return Double squareRoot  

* @throws BadInputException  

* @pre square\!= null  

* @pre square > 0 

*/

public Double SqrRt(Double square); 

This javadoc above contains the familiar @param, @return, and @throws. It also contains a partial contract: the two @pre. This partial contract guarantees that, if these two pre-conditions are met, the SqrRt method will perform its function. If the two pre-conditions are not met, then the caller should not expect SqrRt to do anything useful. Notice that the pre-conditions are specific. They make true/false statements.

/**

  * BAD EXAMPLE:

  * Compute square root.

  * @param square

  * @return Double squareRoot

  * @throws BadInputException

  * @pre all inputs are valid

  */

public Double SqrRt(Double square); 

The code above represents a badly documented contract.

I called the first example a partial contract, because it has no post-conditions. So while we know how to make SqrRt work, we don't know what it does. All methods should have post-conditions.

It may be that some methods have no pre-conditions. These methods would be guaranteed to work no matter what. The only methods that have no post-conditions should be those methods that have no effect. Such methods should be removed.

post-conditions

The post-conditions are part of a contract on methods. The post-conditions list, one by one, the things that will be true if the method succeeded. This list should provide a complete description of the behavior of the method.

/**

  * GOOD EXAMPLE:

  * Compute square root.

  * @param square

  * @return Double squareRoot

  * @throws BadInputException

  * @pre square\!= null

  * @pre square > 0

  * @post squareRoot \!= null

  * @post squareRoot * squareRoot == square

  */

public Double SqrRt(Double square); 

The two @post javadoc comments tell us the result of calling this method. The method must ensure that both post-conditions are true before it returns. If the method cannot met its contract then it should throw an Exception. The only time that should happen is for events beyond system control (Out of memory) or if one the pre-conditions was not true.

Post-conditions should be complete (describe all the effects of calling a method), and specific.

/**

  * BAD EXAMPLE:

  * Compute square root.

  * @param square

  * @return Double squareRoot

  * @throws BadInputException

  * @pre square\!= null

  * @pre square > 0

  * @post returns computed value

  */

public Double SqrRt(Double square); 

The code above represents a badly documented contract.

All methods should have post-conditions.

class invariants

Class invariants are a class-level contract. They apply to all public methods in a class. Class invariants define a stable class.

A class invariant states something about an instance of the class. A class invariant should be true when calling any public method. In this way a class invariant is similar to a pre-condition that applies to every public method in a class.

A class invariant should be true after exiting any public method. In this way a class invariant is similar to a post-condition on every public method. Unlike post-conditions,
class invariants should be true, even if you exit the public method by throwing an exception. The only time a class invariant may be false is during the execution of a public method. If a class invariant is false at any other time, your object is unstable, and probably unusable.

/**

  * GOOD EXAMPLE:

  * Very simple accounting class.

  * @inv transactions \!= null

  * @inv transactions.size() >= 0

  * @inv sum(transactions) == balance

  */

public class SimpleAccount { 

public static double sum(Collection<Double> transactionHistory); 

public double balance = 0.0; 

public Collection<Double> transactions = new LinkedList<Double>(); 

public void deposit(double credit); 

public withdraw(double debit); 

  } 

The invariants in this class define the working conditions for the public methods in this class. If any single invariant is not true, then we have an object that is probably not reliable. It is the job of all of the public methods to make sure that each invariant is true before that method executes a return or throws an exception.

Sometimes it is difficult to think of class invariants. Often they are simple, obvious things:

• an instance variable is initialized
• a lazy initialization method doesn't return a null
• instance variables maintain certain relationships (like the sum of the transactions being equal to the balance)
• instance variables stay within certain ranges.

Some classes have no invariants. This is because they have no state, only behaviors. Java's Comparator is a class with no invariants. If your class has behaviors only, it may not have invariants. If you can't think of the invariants for your class, ask yourself, "does my class have any state".

Like the other parts of the contract, class invariants should be specific.

/**

  * BAD EXAMPLE:

  * @inv properly initialized

  * @inv running in a working system

  */

The above example are not good invariants.

Use of Contracts

If contracts are just a style of javadoc, they would be much less useful to you than if you use them. You use contracts as checklists. You can use these checklists along with a few rules of thumb to guide your work at design, implementation, and test tasks. Doing so will help you to write code that is more concise, coherent, and correct.

Contracts as a design tool

Contracts can be used by designers in several ways.

• Classes with stubbed methods and contracts can give more specific direction to developers who are trying to implement your design.
• As noted above, class invariants can give designer a clue: if you do not intend for a class to be stateless, you should be able to define an invariant.

Contracts can also help you to check the correctness of your class hierarchy.

• In any subclass, overridden methods may have fewer pre-conditions than in the superclass. They may not have additional pre-conditions.
• In any subclass, overridden methos may have additional post-conditions than in the superclass. They may not eliminate any post-conditions.

If you've violated either of these rules, then you should rethink your class hierarchy. Maybe you've declared the wrong class to be the superclass. Maybe you've got the wrong classes altogether. Maybe you need to divide program functionality in a different fashion.
For an explanation of why this works, see the page on the Liskov Substitution Principal.

Contracts during implementation

Contracts provide help during implementation.

• Before returning from a method, are all of the post-conditions true?
• Before returning from a method, are all of the invariants true?
• Before I call a helper method, have I met all of the pre-conditions?
• Do any of my helper methods post-conditions conflict with my method's post-conditions? If so, I need to write some clean-up code.
• If my method's pre-conditions are not met, I can throw an exception.
• Before throwing an exception, are all of the invariants true?

Contracts can, and should, change during implementation.

• The developer may discover that one of the pre-conditions isn't needed.
• The developer may discover additional pre-conditions that are needed.
• The developer may discover side-effects of the method and add them to the post-conditions. This doesn't mean that the side effects are now required behavior of the method, it means that the post-conditions should document all of the behavior of the method.
• The developer may discover new invariants when implementing a class.

The developer should update the contracts to correctly describe the requirements and behavior of methods, and to describe the stability of the class. When you update a contract, you should use the contract to verify that the design is still good. This will help you to avoid unexpected side-effects of your code, and to discover and fix design problems quickly.

It is a good idea to update your contract and review the contract as soon as you realize that the contract will change. This can keep you from writing problem code.

Contracts as documentation

When properly maintained, contracts provide a complete and concise description of class behavior. If you are actually using the contracts for design and implementation, it is very likely that they will be maintained. So developers who wish to use a class can rely on the contracts to explain exactly how the class methods work.

Contracts and unit testing

Contracts provide help in developing unit tests.

• For happy-path tests, call a method and then verify that each post-condition and each invariant is true.
• For negative tests, violate a precondition and call a method. This should be roughly equivalent to provoking the exceptions thrown by the method.
• For negative tests, verify that invariants are true, even after a method has failed.
• For test completeness, look at each post-condition. If that post-condition is ever false, is there some test case that will fail?

Contracts are especially helpful in a test-first shop. You can pick a post-condition, write a test for it, verify that the test fails, write the production code, verify that the test passes, and repeat. See Daily Development Practice.

Functions that use pointers or references to base classes must be able to use objects of derived classes without knowing it.

Robert C. Martin氏为我们总结了在面向对象的设计（OOD）中应该遵循的原则，这些原则被称为“Principles of OOD”，关于“Principles of OOD”的相关文章可以从Object Menter得到。
本文介绍“Principles of OOD”中的里氏替换原则：Liskov Substitution Principle (LSP)。

里氏替换原则LSP的概念解说Functions that use pointers or references to base classes must be able to use objects of derived classes without knowing it.
所有引用基类的地方必须能透明地使用其子类的对象。也就是说，只有满足以下2个条件的OO设计才可被认为是满足了LSP原则：
- 不应该在代码中出现if/else之类对子类类型进行判断的条件。以下代码就违反了LSP定义。
if (obj typeof Class1) {
    do something
} else if (obj typeof Class2) {
    do something else
}
- 子类应当可以替换父类并出现在父类能够出现的任何地方，或者说如果我们把代码中使用基类的地方用它的子类所代替，代码还能正常工作。
里氏替换原则LSP是使代码符合开闭原则的一个重要保证。同时LSP体现了：
- 类的继承原则：如果一个继承类的对象可能会在基类出现的地方出现运行错误，则该子类不应该从该基类继承，或者说，应该重新设计它们之间的关系。
- 动作正确性保证：从另一个侧面上保证了符合LSP设计原则的类的扩展不会给已有的系统引入新的错误。
类的继承原则：
Robert C. Martin氏在介绍Liskov Substitution Principle (LSP)的原文里，举了Rectangle和Square的例子。这里沿用这个例子，但用Java语言对其加以重写，并忽略了某些细节只列出下面的精要部分来说明 里氏替换原则 对类的继承上的约束。
代码：
class Rectangle {
double width;
double height;
public double getHeight() {
return height;
    }
public void setHeight(double height) {
        this.height = height;
    }
public double getWidth() {
return width;
    }
public void setWidth(double width) {
        this.width = width;
    }  
}
class Square extends Rectangle {
public void setHeight(double height) {
        super.setHeight(height);
        super.setWidth(height);
    }
public void setWidth(double width) {
        super.setHeight(width);
        super.setWidth(width);
    }
}
这里Rectangle是基类，Square从Rectangle继承。
这种继承关系有什么问题吗？
假如已有的系统中存在以下既有的业务逻辑代码：
void g(Rectangle r) {
    r.setWidth(5);
    r.setHeight(4);
    if (r.getWidth() * r.getHeight() != 20) {
        throw new RuntimeException();
    }
}
则对应于扩展类Square，在调用既有业务逻辑时：
        Rectangle square = new Square();

;     g(square);
时会抛出一个RuntimeException异常。这显然违反了LSP原则。
动作正确性保证：
因为LSP对子类的约束，所以为已存在的类做扩展构造一个新的子类时，根据LSP的定义，不会给已有的系统引入新的错误。
Design by Contract根据Bertrand Meyer氏提出的Design by Contract（DBC：基于合同的设计）概念的描述，对于类的一个方法，都有一个前提条件以及一个后续条件，前提条件说明方法接受什么样的参数数据等，只有前提条件得到满足时，这个方法才能被调用；同时后续条件用来说明这个方法完成时的状态，如果一个方法的执行会导致这个方法的后续条件不成立，那么这个方法也不应该正常返回。
现在把前提条件以及后续条件应用到继承子类中，子类方法应该满足：
１）前提条件不强于基类．
２）后续条件不弱于基类．
换句话说，通过基类的接口调用一个对象时，用户只知道基类前提条件以及后续条件。因此继承类不得要求用户提供比基类方法要求的更强的前提条件，亦即，继承类方法必须接受任何基类方法能接受的任何条件（参数）。同样，继承类必须顺从基类的所有后续条件，亦即，继承类方法的行为和输出不得违反由基类建立起来的任何约束，不能让用户对继承类方法的输出感到困惑。
这样，我们就有了基于合同的LSP，基于合同的LSP是LSP的一种强化。
在很多情况下，在设计初期我们类之间的关系不是很明确，LSP则给了我们一个判断和设计类之间关系的基准：需不需要继承，以及怎样设计继承关系。

今天听到一个老外说 two more， 晕了一下，感觉他说的是两个多啊，但是事实上只有两个啊，忍不住查了一下，原来如此。高中后没有看过语法了，真的生疏了，需要看看了。

two more 的意思是 还有两个！

谈another, other, more修饰数词的用法

安徽 王玉峰

请看NMET2000单项选择第16题：

If you want to change for a double room you'll have to pay ____ ＄15．

A．another B．other C．more D．each

该句的意思是“如果要换一个双人间，你还需再付15美元”。从题干“change for”可知已订过房间，现在要换只需再加15美元就行了。备选项D的意思是“每个”，不符合题意，A、B、C都可修饰数词，表“额外的、另外的”意思，它们之间的差别在于修饰数词的位置不同，这也正是本题的考查重点，现对another，other，more的这种用法归纳如下：

一、another

another表“另一个”时只跟可数名词单数，而表“另外的、额外的、附加的”之意时，可跟带有few或具体数字的复数名词，此时可把“数词＋复数名词”看作是一个整体。如：

1．—Have you finished your report yet？

—你的报告完了吗？

—No，I will finish it in 10 minutes．

—没有，还需10分钟。

A．another B．other C．more D．less

（NMET'95第27题key：A）

2．The strike may last another three days．罢工可能还要持续三天。

3．There is room for another few people in the back of the bus．公共汽车后面还能坐下几个人。

4．I'll be here for another few weeks．我在这儿还要呆几个礼拜。

二、other

表“另外的”接复数名词，如与具体数词连用，则置于数词之后，但与定冠词the连用时，other要放在数词前。如：

1．Tony is going camping with ____boys next Sunday．托尼将于下周日与另外两个男孩一起去野营。

A．little two other B．two little other

C．two other little D．little other two

（NMET'93．第11题key：C）

2．Mr Smith asked me to fetch three other recorders．史密斯先生让我再拿三台录音机来。

3．Do you know where he found the other two photos？你知道他是在哪儿找到另外两张照片的呢？

三、more

1．more一般位于数词之后名词前，有时也可置于名词之后。如：

（1）She has got five more electric fans．她还有五台电扇。

（2）One more step（One step more），and I'll shoot you．再走一步，我就开枪打死你。

（3）Where shall we be in ten more years？再过十年，我们会在什么地方呢？

2．more除跟数词外，还可与a little，a few，a lot，several等词连用，而且名词也可是不可数名词。如：

（1）I'd like to buy a few more copies of English Weekly．我想再买几份《英语周报》。

（2）There are many more dictionaries on the desk．课桌上有许多词典。

（3）Would you like some more tea？再喝点茶好吗？

四、名词省略

如果前后意思清楚，another或more后面的名词可以省去。如：

1．I climbed the stairs slowly，carrying a big suitcase，my father following with two more．我拎着一个大手提箱，所以爬楼梯很慢。父亲跟在后面，拎着另外两个手提箱。（NMET2000完形填空正文首句）

2．I have had one cup of coffee，but I'd like another．我喝了一杯咖啡，还想再来一杯。

3．I should like to have many more（books）．我想多要几本书。

从以上分析，我们不难看出NMET2000第16题应该选A。

《英语周报》

    一直以来对美国都比较感兴趣，这次由于出差三个月的原因，终于有机会去美国一趟了，我想了解的包括，但不限于：

• 美国人的生活是美剧里的那种生活吗？
• 真正的美国老百姓的生活是什么样的？
• 美元的购买力到底怎么样？
• 美国为什么有目前最现在的生产力？
• 美国的潜力如何，中国是否可以在未来的百年内超越美国？
• 美国的政治制度和体制是解放生产力的因素吗？
• 彰显个性，鼓励创新冒险是所有美国人的共性，还是某些人的个性？
• 美国贫富差距怎么样？大部分老百姓是否满意自己的生活？

    我希望这些很久以前就撒下的谜团可以重重解开，当我离开美国时，我希望自己不但带着美元，还带着答案，带着体会。

1，在路上

    由于路上时间比较紧张，大部分相片都是手机直接拍的，我是9月1日5点半起床的，洗涮完毕后，6点整，念念送我出去打的，时间不巧，出去一问，刚好是司机交接班的时候，但是有福之人不用忙的，路口停着一个杭州公交的载人小巴，也就能载7个的那种吧，司机知道我去坐飞机后，给我出主意说，我带你去司机接班后必经的路口，去了你肯定很快可以等到，也只要个打的钱。我同意了，当出租车缓缓启动的时候，我的鼻子酸了一下，看着念念，毕竟三个月不能见面，是目前为止最长的。之后就是去黄龙体育中心的路上了，一路上想念念。

    到了黄龙，发现有几个同事已经来了，卖票的可还没有来呢，到上海浦东机场最早的大巴了，买票后上了大巴，一路上说说笑笑10点多去了浦东机场，弄行李，安检，终于到了候机厅，看到了久违的UA航班。

    美国理发很贵，最便宜的也要15美元，不知道够我在国内理几年的发了，大部分同事们都出发前两天理了寸头，我也不例外。呵呵。

    UA的这次航班非常大，座位排到60多排了，我在倒数第四排坐，比较晃，早知道就网上调到前面了。长途飞行不是国内航班，过道比靠窗可抢手多了，毕竟可以随意起来走动走动啊。

   飞机上睡觉基本不可能，我是睡不着啊，和旁边的哥们聊了很多，他是硕士毕业后，加入了趋势，到美国旧金山工作的，L1签字，一年也就回国度假一次。

    经过10小时煎熬，终于下飞机了，旧金山的阳光非常烈，非常直接，好像天空没有一点阻碍一样暴露在太阳下。

    又是拿行李，办入关手续，非常顺利通过了。

    在候机厅等待时，就不像浦东机场了，周围全是老美。

    登上了从旧金山到丹佛的飞机后，到了我的位置，果然靠窗，哈哈，可以欣赏一下北美中部，山地风景了。

   这一路以来，还是一点困意没有，旧金山起飞后，先是一个大湖，很多人在玩帆船，划出了很多美丽曲线，然后就是广袤的平原和草原了，大自然的鬼斧神工，有的地方象中国的山水画，有的象景泰蓝，有的想鎏金画，有的想粗糙的蓝白刺绣，还有一片地方，非常想一个藏传佛教的大佛坐像，和杭州飞来峰造像神似，一个是自然神笔绘出人的信仰，一个是人的神笔绘出自然的奇迹，还有几处象极了的，有一个鲤鱼的地表，水渠所成，反光后极像鎏金效果的画；一个是人的全身像，写实的，蓝白色，还有很多飘逸的图像，象是敦煌的飞天一般。当时不禁感叹，如果当年郑和“殖民”了这片大好河山……

    慢慢就到美国中部了，从旧金山起飞到丹佛，基本没看到城市，相反，非常荒凉，空气非常好，地貌非常清晰的展现在你眼前。

    终于在飞机上看到丹佛了，全是二、三楼的房子，只有市中心有10几个高楼，地面非常平，空气非常好，看到下面的无数车道上，那些汽车好像一个人的血脉般流动，就知道支撑这个国家的是什么，石油！

    下飞机了，阳光一样很晒，原因包括了丹佛海拔是1000公尺的，比杭州，长沙和太原都高！

 
    有趣的是那里的地平线太平了，kan说以前这里都是草原的，也就难怪平了，丹佛最初的名字是Queen Lang of Plain。

to be continued...