瞎扯淡: 仁言利博

5年,从3500到700万

Sun, 28 Aug 2005 05:39:15 GMT

一篇非常非常非常好的文章

有点长...

想看的人可以去看下..

我希望能到我这来的人都去看下..

讲诉的是一个从新疆到上海的男人奋斗历程

不要管它的真实性..只希望你把它当真实的看

其中总结的句子拿来转一下,我不知道MSN SPACE如何置顶贴,如果可以.此文一定置顶

1，人生就是投资和收益的人生。如果你有钱，就投入金钱；如果你没有金钱，而有经验和能力，就投入经验和能力；如果你既没有金钱，也没有经验和能力，但是你有热情、勤奋和努力，那就投入热情、勤奋和努力。如果你既没有金钱，也没有经验和能力，连热情、勤奋和努力也没有，那就别想这些了。

2，比赚钱更重要的是找到你自己的赚钱动力；

3，比金钱重要的是时间，比时间重要的是时机，比时机重要的是你要抓住时机的决心，动力和准备！

4，别好高骛远，机会一般都在你看不起眼的角落里藏着；

5，舍得投入；

6，决定一下，行动要快；

7，永远尽可能准备好资源，随时准备抓住机会，要快！

8，待人以诚，对人以善。有时候，机会是别人给的；

9，给别人的比别人期待的多一些（李嘉诚的）；

10，赚钱有个普遍的法则：多做，快做，动脑筋变着花样做，就是别跟着别人一样做。

11，合理规划有钱以后的日子，会让你走的更远；

12，有信仰，有原则，有爱心。

(转载)一篇很好的flash oop教程

Thu, 10 Mar 2005 15:57:20 GMT

本来想放进链接的..但又实在怕这篇文章被删除..还是转到自己blog上比较放心..

5shan 发表在我闪推荐

有人问我flash的as应该怎么写，我可以很负责任地告诉他，想怎么写就怎么写，因为as以及flash内部的构成模式决定了它的高度自由化。理论上来说，用按钮的on事件，加上stop()，play()，gotoAndStop()，gotoAndPlay()，就可以实现一个flash里大部分的逻辑关系，而且源代码简单易懂。但是大多数人不会这么做，是因为这种方法实在太让人敬佩。稍有常识的程序员都会知道面对对象与面对过程的区别。Flash的编程虽然只是以脚本的形式出现，并且还很不完善，比如，没有多继承，但已经初步体现了oop的思想。这篇文章现在总结一下flash中面对对象的设计模式问题，以及一些自创的思路。

设计模式是美国一位建筑大师（同时也是信息工程师，画家，机械工程师…的）克里斯蒂安.亚历山大首先提出来的，很快被软件界的技术员们所接受推广，成为软件工程里至高无上的法则之一（有兴趣的人可以找他的《建筑的永恒之道》一书看看，相信会受益非浅）。简单地说就是在面对对象的基础上，包括面对对象，把要设计的整体的各个部分模式化，层次化，细粒度化，高度复用化，可控化，人性化。其中至高无上的原则是建立在需求的基础之上，也就是说，无论做什么，人的需求要放在第一位考虑，从这个角度考虑整个系统是否足够合理。这门学问是非常有趣的，尤其在flash中，可以应用到很多很好玩的实例中去。下面我按照一些通用的设计模式，举例说明，有错误的地方，敬请高手指正：

1．抽象工厂模式（Abstract Factory）
食堂里吃的东西很多，而我只想吃一样，那么食堂这个概念对我来说就是个抽象工厂，每个窗口可以看成它的一个具体实现，我要做的就是，去食堂，找到那个窗口，从窗口里买我要吃的东西。

举例：flash前台与asp后台的交互，访问某个动态页面，从数据库里取出需要的数据，通常的做法是在后台就把数据集解析成xml字符串，再送给swf。每个业务逻辑模块，所取出的数据结构，也就是xml的结构是不一样的，我们要针对各个具体的业务逻辑，对相应的xml字符串解析，转换成可供显示的数组。也要把flash里文本输入的内容转换成 xml字符串，提交给后台也面

AbstractFactory.as
//抽象工厂的接口
Interface AbstractFactory{
//生成xml解析工厂的具体实现
function createXmlParseFactory();
}

XMLParserGetFactory.as
//生成解析读入的xml的对象的工厂
class XMLParserGetFactory implements AbstractFactory.{
var xmlParser;
function XMLParserGetFactory(str:String){
//生成解析器的具体实现，在后面会提到
}
function createXmlParser(){
return xmlParser;
}
}
XMLParserPostFactory.as
//生成解析输出的xml的对象的工厂
class XMLParserPostFactory implements AbstractFactory.{
var xmlParser;
function XMLParserPostFactory(str:String){
//生成解析器的具体实现
}
function createXmlParser(){
return xmlParser;
}
}

这样，我们读入某个xml字符串时，在onLoad里面加入
//生成对留言板的留言列表解析的工厂
var xmlParser=new XMLParserGetFactory(“xmlParseGuestbookList”)
xmlParser= XMLParserGetFactory. createXmlParser()

备注：抽象工厂模式是软件工程里最常用的设计模式之一，实现过程在于，需要某个类的实例时，通过某个工厂创建，而不是直接创建，坦白地说，它加大了开发工作量，但是对程序的层次性变得分明和降低耦合度有极大帮助。

2．生成器模式（builder）
还是那个说法，我要吃东西就去相应的食堂窗口，但我不能吃食堂窗口，窗口里的东西也许不少，我要跟师傅说，要这个，这个，还有这个。

举例：我已经建立了 xml解析器的工厂，现在要返回解析器本身，就让工厂创建，返回给我。

XMLParserGetFactory.as
//生成解析读入的xml的对象的工厂
class XMLParserGetFactory implements AbstractFactory.{
var xmlParser;
function XMLParserGetFactory(str:String){
//如果要求留言板列表解析器，就生成一个
if(str==” xmlParseGuestbookList”){
xmlParser=new xmlParserGuestbookList();
}
}
function createXmlParser(){
//返回所要求的解析器
return xmlParser;
}
}

AbstractXmlParser.as
//抽象xml解析器
Interface AbstractXmlParser{
function ParseXml();
}
xmlParserGuestBookList.as
//留言板列表解析器
Class xmlParserGuestBookList implements AbstractXmlParser{
//把xml字符串里的内容解析到一堆数组里
function ParseXml(xml:XML,arrayID:Array,arrayTitle:Array){
//具体循环操作
}
}

使用的时候：
var xmlParser=new XMLParserGetFactory(“xmlParseGuestbookList”)
xmlParser= XMLParserGetFactory. createXmlParser(xml,arrayID,arrayTitle);

3．工厂方法模式（Factory Method）
我到了食堂窗口，如果师傅跟那儿抽烟，我还是吃不着东西。我说：师傅，打饭！师傅才会完成打饭这一动作。这是工厂方法模式，抽象工厂的实现通常用工厂方法模式来完成。

举例：还是上一条，我本来想用一句话带一个参数就实现具体xml解析器的实现，无奈构造函数没有返回值，所以必须用
xmlParser= XMLParserGetFactory. createXmlParser(xml,arrayID,arrayTitle);
实现。

备注：抽象工厂模式，生成器模式和工厂方法模式需要灵活应用。

4．单件模式（singleton）
我前面一个人买了一条巨大的鸡腿，我说我也要一条，师傅说，就这一条

举例：单件模式的应用是相当广泛的，它确保每个实例在全局范围内只被创建一次，我们flash里的mc大多数是单件。内核里的核心组件也只是单件，比如我的消息映射列表（见后）。
按照单件模式的严格定义，应该让类负责保存它的唯一实例。但是我在Flash里还想不到怎么实现这一点，或者实现它的意义所在，但另外一点我们可以做到，就是在全局范围内只提供该对象的唯一访问点。这可以由层次关系做到，把对该对象的访问具体实现全部封装在下层，只给上层提供唯一的访问点（原因是，上层不知道这个单件的具体信息，比如路径）。
看我内核文件的一部分：
Core.as
//内核
class Core {
var strucGlobalParam:ConfigVariables;
//站点信息
var xmlConfig:XML;
//站点信息的xml化对象
var ArrayStructureInitial:Array;
//用来提供给loadObject对象的数组
var ArrayForBtn:Array;
//用来初始化导航条组件的数组
var objInitial:loadObject;
//读取影片的对象
var objMessageMap:MessageMap;
//消息映射组件
……
}
这是我的内核类也就是全站最核心类的数据结构。里面的数据只有通过下层的BasicMovie，OriginalFunctionObject等类（见后）直接访问。

备注，核心思想是，确保只有一个。

5．原型模式（protoType）
到小炒窗口，看前面的哥们炒的青椒炒肉不错的样子。“师傅，我也要这样的。”

举例：这对flash的用户来说再熟悉不过了，我们经常用duplicateMovieClip()和
attachMovie()这两个函数。按照一个原型复制相应的实例，各自执行自己的动作。在我的blog列表，导航条的生成。。几乎用得到多项数据的地方就要用原型模式。

6.责任链模式
7.中介者模式
8.观察者模式
食堂里厨房最远的窗口没熬白菜了，要告诉厨房，快送过来。
责任链模式：一个窗口一个窗口地传话，一直传到食堂，食堂一看不妙，赶快做好送过去。
中介者模式：专门派一个人负责传话，任何窗口没菜了，就要这个人赶快去厨房催。
观察者模式：厨房那边派一个盯着，看哪个窗口没菜了就开始大声嚷嚷。

举例：之所以要把这三个设计模式放在一块儿，是因为我在我的站里面结合这三者建立了一个好玩的东西，可以说是我的网站的核心所在。它解决了我的flash里面各个mc的通信问题。
比如，影片A放完了，要通知影片B开始播放，直接的做法是在A的最后一帧，写从A到B的相对路径或B的绝对路径，让B play()。这样做A和B的耦合性是相当高的，也就是说，相互依赖程度太高。运用设计模式的解决方案如下：

MessageMap.as
//消息映射类
class MessageMap extends Object {
var Message:String;
var MessageWatcher:Function;
var Target;
var MessageList:Array;
var Num_Msg:Number;
function MessageMap() {
Num_Msg = 0;
MessageList = new Array();
Message = "HANG_UP";
MessageWatcher = function (prop, oldVar, newVar, Param) {
for (var i = 0; i<Num_Msg+1; i++) {
if (newVar == MessageList[i][0]) {
MessageList[i][1].apply(MessageList[i][3], MessageList[i][2]);
if (!MessageList[i][4]) {
MessageList.splice(i, 1);
Num_Msg--;
i-=1;
}
}
}

};
this.watch("Message", MessageWatcher, "test");
}
function SendMessage(Msg:String, mc:MovieClip) {
Message = Msg;
}
function UpdateMessageMap(Msg:String, objFunction:Function, ArrayParam:Array, objRefer,IsMultiUsed:Boolean) {
MessageList[Num_Msg] = new Array();
MessageList[Num_Msg][0] = new String();
MessageList[Num_Msg][0] = Msg;
MessageList[Num_Msg][1] = new Function();
MessageList[Num_Msg][1] = objFunction;
MessageList[Num_Msg][2] = new Array();
MessageList[Num_Msg][2] = ArrayParam;
MessageList[Num_Msg][3] = objRefer;
MessageList[Num_Msg][4] = IsMultiUsed;
Num_Msg++;
}
function DeleteMessageMap(objRefer) {
for (var i = 0; i<Num_Msg; i++) {
if (MessageList[i][2] == objRefer) {
MessageList.splice(i, 1);
Num_Msg--;
}
}
}
}

class SubTemplateMovie extends BaseMovie {
var MovieRemoveFunction:Function;
function SubTemplateMovie() {
this.stop();
MovieStartFunction = function () {
Lock();
this.play();
};
MovieEndFunction = function () {
Lock();
this.play();
};

MovieRemoveFunction = function () {
this.stop();
SendMsg("SUB_TEMPLATE_REMOVED", this);
_parent.unloadMovie();
};
MovieMainFunction = function () {
stop();
SendMsg("SUB_TEMPLATE_OPEN", this);
};
UpdateMessage("LOADING_BAR_OVER", MovieStartFunction, null, this, false);
UpdateMessage("BACK_TO_INDEX", MovieEndFunction, null, this, false);
}
}

大概机制就是，影片提前提交一个数据结构，声明，如果有影片提交这条消息，就执行这条函数。原理在于，发送消息，实际上是把消息映射的一个变量赋值，由于消息映射继承自object类，可以用watch方法对该变量进行监视，一旦改变，在已经提交上来的消息映射列表里检查，如果有，执行对应函数。实际上这也造成了一定程度的耦合性，但是我们已经成功地把耦合性控制在了下级类，上级子类完全不用理会这一套消息机制的实现过程。

这个机制可以让我们对oop的真正目的有更深的看法。举例说明，影片A播放完了，就声明自己播放完了，至于我播完了你要干什么，不是我的事，我不控制你。所谓的降低耦合度是个相对概念，别忘了在计算机最底层，耦合度还是一样，cpu总是不断的直接或间接寻址，但我们需要做的是，改变系统的拓扑结构，把耦合度控制在某一个范围之内。

整个消息映射类相当于一个中介者，内部生成一个观察器，一旦触发消息，以责任链的方式执行。

9.桥接模式（Bridge）
菜太淡，不合有些人的胃口，所以要求食堂的师傅，专门开一个窗口，专门在做好的菜里多加些辣椒。

我在自己的站里运用了桥接模式：所有的影片都继承自我定义的BasicMovie 类（BasicMovie继承自MovieClip类），但是在四个下级栏目的影片里，需要定义相同的方法和事件来响应消息，BasicMovie没有这些函数，不符合要求，这时候，在四个影片里都写一遍是愚蠢的，我又写了一个SubTemplateMovie类继承自BaseMovie，里面加进一些通用的方法，然后四个下级模板影片都继承它，这样大大简化了后期开发。

BasicMovie.as
//基类影片
/所有影片的原始类，一切影片的父类都继承此类而来
class BaseMovie extends MovieClip {
var isLocked:Boolean;
//初始类开始影片函数
var MovieStartFunction:Function;
//初始类影片主功能函数
var MovieMainFunction:Function;
//初始类结束影片函数
var MovieEndFunction:Function;
var GlobalParam
//初始类构造函数
function BaseMovie() {
}
//

//发送消息
function SendMsg(Msg:String, Mc:MovieClip) {
_root.objCore.objMessageMap.SendMessage(Msg, Mc);
}
//添加消息映射
function UpdateMessage(Msg:String, MsgMapFunction:Function, ArrayParam, obj, IsMultiUsed) {
_root.objCore.objMessageMap.UpdateMessageMap(Msg, MsgMapFunction, ArrayParam, obj, IsMultiUsed);
}
//删除消息映射
function DeleteMessage(obj) {
_root.objCore.objMessageMap.DeleteMessageMap(obj);
}
function GetGlobalParam() {
GlobalParam=_root.objCore.strucGlobalParam;
}
}

SubTemplateMovie.as
//下级模板影片类
class SubTemplateMovie extends BaseMovie {
var MovieRemoveFunction:Function;
function SubTemplateMovie() {
this.stop();
MovieStartFunction = function () {
Lock();
this.play();
};
MovieEndFunction = function () {
Lock();
this.play();
};

MovieRemoveFunction = function () {
this.stop();
SendMsg("SUB_TEMPLATE_REMOVED", this);
_parent.unloadMovie();
};
MovieMainFunction = function () {
stop();
SendMsg("SUB_TEMPLATE_OPEN", this);
};
UpdateMessage("LOADING_BAR_OVER", MovieStartFunction, null, this, false);
UpdateMessage("BACK_TO_INDEX", MovieEndFunction, null, this, false);
}
}
注（关于消息映射机制看责任链模式）

10.适配器模式（Adapter）
我要一碗汤，但是只有纸饭盒，还没勺，所以食堂的师傅给了我一次性的汤碗和勺，这叫适配器。

适配器解决的是某一个类的对外接口不合用的问题，可能是参数或者返回值类型不符等问题造成的，这时候我们需要在工作对象和这个类之间加一层间接的层次。
这个模式我在底层的数据交换层用过。我说过，flash和asp.net之间交换数据全以xml为载体。返回xml在底层只有三层，数据库操作，数据操作，数据显示，由数据操作层返回给数据显示层一个xml字符串就可以了。然后我就遇到一个小问题，在另一方面，我需要提交数据到数据库，也是提交一个xml字符串，但是我需要数据库里对应的表的数据集的xml表现形式的xsd验证！（一口气说完，差点没憋死）。就是说我至少需要取出这个表里的一条记录，问题在于，我封装的类从来只返回xml，没有返回xsd的。解决办法就是适配器，新建一个项目，加了一层专用于获得xml验证格式，这样就完成了不同接口之间的转换。

备注：适配器和桥接很象，都是在已有类不符合要求的时候，加入一层间接的元素以达到目的。不同的是适配器是解决不兼容接口之间的转换，桥接一般不涉及这个问题，只是完成一个一对多的转换。

11.外观模式（Facade）
每天都要去食堂，每个人去不同的窗口吃不同的菜，很累，今天全寝室推举猴子去打饭：
你吃这个，三两饭，我吃那个，五两饭，所有人都只跟猴子一个人交涉，食堂所有的师傅也只见猴子一个人。

举例：这个模式在程序的上下层的通信之间可以应用得十分广泛。Asp的每个模块要去不同的数据，访问数据库的不同表，就要跟不同的下层数据访问组件打交道。就是说，每个mc模块必须知道，我要去哪个具体的数据访问组件取数据。每个模块要维持自己的一个，至少是字符串。
如果运用外观模式。我们可以让所有的需要数据交互的mc访问同一个aspx页面，比如getStrXml.aspx。只要传送一个标示符，就可以通知这个唯一的取数据的叶面，访问哪个下层组件获取数据。下层组件不知道哪个mc要求数据，mc也不知道数据的具体来源，这样，上下层之间互相都显得不透明。这就降低了耦合度。

12.代理模式（Proxy）
可能我们不是每个人每天都想吃饭，所以我们要求猴子每天中午必须在寝室，如果我们要吃，他就去，如果我们都不吃，他爱干嘛干嘛。

举例：这恐怕是每个人在flash里都会无意中用到的模式。比如，一个网站，它的下级栏目不用在整个网站初始化的时候一开始就读进来，但是我们要确保，在浏览者想看并且点击导航条上的某个按钮时，能够正确地读进相应的影片文件，前提是，我们必须在内部保留一个索引，可以称作代理。通常是一个空mc

13.策略模式（strategy）
我每天先在食堂找座位，再打饭，再打菜，再买杯酸奶。这已经模式化。要是食堂有服务员，我也会要他这么做。

举例，策略模式是把一系列的算法封装起来，形成一个类。这个模式几乎是随时随地都可以整合到别的模式里去的，我的那一堆xml解析器实际上就是策略模式的应用，这个模式还应用到我网站的下层，因为flash提交给aspx页面的数据也是xml字符串，下层模块也需要相应的解析算法。同样的，我把对xml的解析封装进了一个类。

//Cs文件里的解析函数

Class DataModel.BlogMsgs{
…
Public DataSet parseXML(string strXml){
DataSet ds=new DataSet();
//。。把xml装载到DataSet 里
Return ds
}
…
}

14.享元模式（Flyweight）
东西不够吃？给你摆20面镜子~
师傅，东西还是只有一份。。。

关于这个模式十分抱歉，我暂时还没想到在flash里面的实现。需要举例说明的是，浏览器的机制是，在有大量文字的英文文档里，相同的字母共享一个Flyweight，在内存里其实只占一份空间，然后在文档不同的地方显示，这样对于大量细粒度的效果来说，可以节省很多资源。有哪位同志想到了请一定告诉我，不胜感激。

15.访问者模式（Visitor）
只要愿意，我随时都可以跑到哪个窗口打要吃的东西，前提是，我必须跑这一趟。

举例：我说过，我的所有mc都继承自BasicMovie这个类，但不是我的所有mc都要从后来获取数据库数据。获取数据库数据所要访问的信息，比如ip，路径，文件保存在配置文件里，初始化的时候读入内核，并且只有内核那里有一份。在BasicMovie里加入对这些全局变量的引用是不合适的，因为只有少数mc要用到，而且由于某些原因我无法再使用桥接模式（我已经有了SubTemplateMovie，不能多继承），所以我用了访问者模式。

BasicMovie.as

//获取全局变量
function GetGlobalParam() {
GlobalParam=_root.objCore.strucGlobalParam;
}

如果上级mc不执行这个函数，是不能获取全局变量的，如果要用，就执行。
也就是说，需要的时候，我去访问它。

备注：声明一个visit操作，使得访问者可以正确访问需要的类。

16.状态模式（state）
我今天想吃面，师傅问我：要什么料？西红柿鸡蛋，排骨还是牛肉？

举例：状态模式是指将对象当前的某些状态局部化，当对象改变状态时，看起来好像改变了类。例子还是我的滚动条。如果要滚动的是文本框，就要引用一个TextField的Scroll,maxscroll属性，如果是mc，引用的是_y,_height属性，我用一个参数将二者区分，由一个if语句控制，让滚动条可以自由区别状态。
另外一个解决方案是定义ScrollBar的不同子类，这两者本质区别不大，在状态比较多时，可能要维持一个庞大的if算法，这样就用生成子类的方法比较好。

ScrollBar.as
//滚动条组件
function BindTo(mc,type:String,intMcHeight:Number,yinitial:Number){
ScrollType=type;
if(type=="TXT"){
scrollTxt=mc;
}
if(type=="MC"){
initialY=yinitial;
McHeight=intMcHeight;
scrollMc=mc;
}
}
function Scroll() {
if(ScrollType=="TXT")
this.onEnterFrame = function() {
scrollTxt.scroll = scrollTxt.maxscroll*mcBlock._y/(BgLength-BlockLength*3/2)
};
if(ScrollType=="MC"){
this.onEnterFrame=function(){
if(scrollMc._height>McHeight){
scrollMc._y=initialY-(scrollMc._height-McHeight)*mcBlock._y/(BgLength-BlockLength*3/2)}
}
}
}

备注：这也是常见模式，在flash的逻辑控制里尤其随处可见

17.装饰模式（Decorator）
在食堂吃饭，没筷子怎么行？我是从来不带饭盆的。师傅很人性化，每个窗口都放着一大把筷子，随用随拿。

这个模式如果用好，有的地方可以很省力。比如，我网站里的滚动条：

ScrollBar.as
//滚动条组件
class ScrollBar extends BaseMovie {
var BgLength:Number;
var BlockLength:Number;
var mcBlock:MovieClip
var Width:Number;
var ScrollType;
var scrollTxt:TextField;
var scrollMc:MovieClip;
var McHeight:Number
var initialY:Number
function ScrollBar() {
}
function InitialScrollBar(BgLength, BlockLength) {
this.BlockLength = BlockLength;
this.BgLength = BgLength;
}
function BindTo(mc,type:String,intMcHeight:Number,yinitial:Number){
ScrollType=type;
if(type=="TXT"){
scrollTxt=mc;
}
if(type=="MC"){
initialY=yinitial;
McHeight=intMcHeight;
scrollMc=mc;
}
}
function Scroll() {
if(ScrollType=="TXT")
this.onEnterFrame = function() {
scrollTxt.scroll = scrollTxt.maxscroll*mcBlock._y/(BgLength-BlockLength*3/2)
};
if(ScrollType=="MC"){
this.onEnterFrame=function(){
if(scrollMc._height>McHeight){
scrollMc._y=initialY-(scrollMc._height-McHeight)*mcBlock._y/(BgLength-BlockLength*3/2)}
}
}
}
function ScrollMc() {

}
function StopScroll() {
this.onEnterFrame=null;
}
function Reset(){
mcBlock._y=0;
}
}

核心函数是BindTo（），把这个滚动条的实例绑定到某个动态文本框或者某个mc上，就可以实现滚动。

备注：装饰模式的思想是，在不影响其他对象的情况下，以动态，透明的方式给单个对象添加职责。

值得珍藏的80句话

Sun, 20 Feb 2005 15:16:19 GMT

01.每天告诉自己一次，“我真的很不错”。
02.生气是拿别人做错的事来惩罚自己。
03.生活中若没有朋友，就像生活中没有阳光一样。
04.明天的希望，让我们忘了今天的痛苦。
05.生活若剥去理想、梦想、幻想，那生命便只是一堆空架子。
06.发光并非太阳的专利，你也可以发光。
07.愚者用肉体监视心灵，智者用心灵监视肉体。
08.获致幸福的不二法门是珍视你所拥有的、遗忘你所没有的。
09.贪婪是最真实的贫穷，满足是最真实的财富。
10.你可以用爱得到全世界，你也可以用恨失去全世界。
11.人的价值，在遭受诱惑的一瞬间被决定。
12.年轻是我们唯一拥有权利去编织梦想的时光。
13.青春一经典当即永不再赎。
14.没有了爱的语言，所有的文字都是乏味的。
15.真正的爱，应该超越生命的长度、心灵的宽度、灵魂的深度。
16.爱的力量大到可以使人忘记一切，却又小到连一粒嫉妒的沙石也不能容纳。
17.当一个人真正觉悟的一刻，他放弃追寻外在世界的财富，而开始追寻他内心世界的真正财富。
18.只要有信心，人永远不会挫败。
19.不论你在什么时候开始，重要的是开始之后就不要停止。
20.不论你在什么时候结束，重要的是结束之后就不要悔恨。
21.人若软弱就是自己最大的敌人。
22.人若勇敢就是自己最好的朋友。
23.『不可能』只存在於蠢人的字典里。
24.抱最大的希望，为最大的努力，做最坏的打算。
25.家！甜蜜的家！天下最美好的莫过于家。
26.游手好闲会使人心智生锈。
27.每一件事都要用多方面的角度来看它。
28.有理想在的地方，地狱就是天堂。
29.有希望在的地方，痛苦也成欢乐。
30.所有的胜利，与征服自己的胜利比起来，都是微不足道。
31.所有的失败，与失去自己的失败比起来，更是微不足道。
32.上帝从不埋怨人们的愚昧，人们却埋怨上帝的不公平。
33.美好的生命应该充满期待、惊喜和感激。
34.世上最累人的事，莫过于虚伪的过日子。
35.觉得自己做的到和不做的到，其实只在一念之间。
36.第一个青春是上帝给的；第二个的青春是KAO自己努力的。
37.少一点预设的期待，那份对人的关怀会更自在。
38.思想如钻子，必须集中在一点钻下去才有力量。
39.人只要不失去方向，就不会失去自己。!
40.如果你曾歌颂黎明，那么也请你拥抱黑夜。
41.问候不一定要慎重其事，但一定要真诚感人。
42.人生重要的不是所站的位置，而是所朝的方向。
43.当你能飞的时候就不要放弃飞。
44.当你能梦的时候就不要放弃梦。
45.当你能爱的时候就不要放弃爱。
46.生命太过短暂，今天放弃了明天不一定能得到。
47.天才是百分之一的灵感加上百分之九十九的努力。
48.人总是珍惜未得到的，而遗忘了所拥有的。
49.快乐要懂得分享，才能加倍的快乐。
50.自己要先看得起自己，别人才会看得起你。
51.一个今天胜过两个明天。
52.要铭记在心；每天都是一年中最美好的日子。
53.乐观者在灾祸中看到机会；悲观者在机会中看到灾祸。
54.有勇气并不表示恐惧不存在，而是敢面对恐惧、克服恐惧。
55.肯承认错误则错已改了一半。
56.明天是世上增值最快的一块土地，因它充满了希望。
57.理想的路总是为有信心的人预备着。
58.所有欺骗中，自欺是最为严重的。
59.人生最大的错误是不断担心会犯错。
60.把你的脸迎向阳光，那就不会有阴影。
61.经验是由痛苦中粹取出来的。
62.用最少的悔恨面对过去。
63.用最少的浪费面对现在。
64.用最多的梦面对未来。
65.快乐不是因为拥有的多而是计较的少。
66.你的选择是做或不做，但不做就永远不会有机会。
67.如你想要拥有完美无暇的友谊，可能一辈子找不到朋友。
68.不如意的时候不要尽往悲伤里钻，想想有笑声的日子吧。
69.把自己当傻瓜，不懂就问，你会学的更多。
70.要纠正别人之前，先反省自己有没有犯错。
71.因害怕失败而不敢放手一搏，永远不会成功。
72.要克服生活的焦虑和沮丧，得先学会做自己的主人。
73.你不能左右天气，但你能转变你的心情。
74.孤单寂寞与被遗弃感是最可怕的贫穷。
75.想象力比知识更重要。
76.漫无目的的生活就像出海航行而没有指南针。
77.好好扮演自己的角色，做自己该做的事。
78.一切伟大的行动和思想，都有一个微不足道的开始。
79.得意时应善待他人，因为你失意时会需要他们。
80.学做任何事得按部就班，急不得。

转一篇真正感动的文章

Mon, 14 Feb 2005 09:30:59 GMT

中国男孩秋(隐去真名)与他的妹妹相依为命。父母早逝，她是他唯一的亲人。所以男孩爱妹妹胜过爱自己。然而灾难再一次降临在这两个不幸的孩子身上。妹妹染上重病，需要输血。但医院的血液太昂贵，男孩没有钱支付任何费用，尽管医院已免去了手术费，但不输血妹妹仍会死去。
作为妹妹惟一的亲人，男孩的血型和妹妹相符。医生问男孩是否勇敢，是否有勇气承受抽血时的疼痛。男孩开始犹豫，10岁的大脑经过一番思考，终于点了点头。
抽血时，男孩安静地不发出一丝声响，只是向着邻床上的妹妹微笑。抽血完毕后，男孩声音颤抖地问：“医生，我还能活多长时间？”
医生正想笑男孩的无知，但转念间又被男孩的勇敢震撼了：在男孩10岁的大脑中，他认为输血会失去生命，但他仍然肯输血给妹妹。在那一瞬间，男孩所作出的决定是付出了一生的勇敢，并下定了死亡的决心。
医生的手心渗出汗，他紧握着男孩的手说：“放心吧，你不会死的。输血不会丢掉生命。”
男孩眼中放出了光彩：“真的？那我还能活多少年？”
医生微笑着，充满爱心地说：“你能活到100岁，小伙子，你很健康！”男孩高兴得又蹦又跳。他确认自己真的没事时，就又挽起胳膊――刚才被抽血的胳膊，昂起头，郑重其事地对医生说：“那就把我的血抽一半给妹妹吧，我们两个每人活50年！”
所有的人都震惊了，这不是孩子无心的承诺，这是人类最无私最纯真的诺言。

在情人节这天里....我希望大家都能看见温暖的文字...

祝各位有情人终成眷属