12
Jul
2013

周未,刷刷 龙井、梅家乌、大清谷

标签: 骑行
10
Jun
2013

2013年海南环岛游记

标签: 摄影 骑行 风景

阅读全文>>

05
Jun
2013

练了两月~略有小成

标签: 钢琴
05
Jun
2013

Whisper of The Rhythms

标签: 钢琴 黑白 摄影

14
Oct
2012

何为信仰?

标签: 哲学

人的不幸在于他们不想走自己的路,而总是想走别人的路。——托马斯·伯恩哈德

 

现在经常能听到国人没有信仰、非常浮躁之类的声音。每当听到这些,我就会想一个问题:到底什么是信仰?是我们常知的佛教道教或者基督教吗?诚然,对于那些僧人,说他们有信仰,我想没人会反对,大概是因为他们会虔诚地去寺庙(礼堂)念经(祈祷)。

 

那是不是说对于红尘中的你我,我们就不可能拥有信仰了?

 

我想当然不是。首先我们从字面上来解释一下这个词,新华词典对“信仰”二字的解释是:“对某种理论、思想、学说极其信服,并以此作为自己行动的指南。这样的解释虽然没有什么错,但似乎层次过高。单从对某种理论、思想、学说极其信服”这方面来说,恐怕就会吓走很多人。因为对于普通人来说,“理论”、“思想”、“学说”之类如此高层次的抽象也许根本不会出现在他们的生活圈中,生活、家庭、事业、友情才是其切身能够感受到的。那就先抛开马克思、黑格尔、孔子之类的思想伟人,从我们身边熟悉的人说起。现在我问你:你觉得微软创始人Bill Gates有没有信仰?你觉得毛泽东有没有信仰?你觉得马云有没有信仰?我的回答是:是,他们都是有信仰的人。并不是说他们都成就了一番事业,而是因为他们都坚定地走在自己的路上,无论受到多大的打击、遇到多大的挫折,从未改变。换句话说,就是因为他们都是有主义的人,他们信仰自己的主义。Bill GatesPaul Allen创建微软时的主义是:A computer on every desktop and in every home;毛泽东的主义是:马克思主,建立一个独立的新中国(这里你可以会认为我被共产党洗脑了,但我想告诉你的是,事实就是事实,如果毛泽东当年没有信仰,那么共产党怎如何在如此坚难的条件下用小米加步枪打下天下的?);马云(或者说李彦宏?)的主义是:让天下没有难做的生意,建立商业生态新环境。没错,正如你看到的,信仰的关键是就看你有没有坚持某种主义。我的朋友,我告诉你,主义是非常重要的东西。一种主义决定了你扛什么旗、走什么样的路!甚至决定你的一生。所以一个人有没有信仰,不是看他是哪门哪派,关键是看他有没有坚持自己的主义、坚持走自己的路!

 

正如本文开头所说的那样,现在的国人非常的“浮躁”、没有“信仰”,其根本的原因就是没有自己的主义,说得更直白点,就是没有找到自己的路。网络、即时通讯工具、社交网络等信息时代工具兴起,使得每人个的信息面得到了前所未有的扩大。同时,人的天性就是报喜不报忧。所以,现在的我们总是看到别人生活得多么多么美好,再对比自己的生活,可能就会感觉强烈的落差,失去自己的目标,开始模仿那个人。

 

 

人总是只看他人光彩的一面,这是我们的天性

 

但过了一段时间后,又看到另一个种生活方式,就又开始模仿另一个人。这样一起,自己的道路就不断地在修改,最终的结果就是失去自我,没有了自己的主义,见风使舵,当然就也谈不上信仰了。请大家回想一下共产党的历史:从最开始的几个人、井冈山、南泥湾开荒、长征中的爬雪山、过草地到打败国民党(你要知道,当时共军的士兵连防弹头盔都没有,可想差距有多大),得天下(当然还差一点点,台湾),这难道不就是一部艰难的创业史吗?我这里并不是想要拍共产党马屁什么的,说实话,我也不是共产党党员。客观地说,我确实比较佩服共产党人,我想,共产党的成功,很大原因是其把自己的主义深深地灌入到了每位“信徒的脑根里。所以我们才会在历史书说学到这么多“宁死不屈”的英雄们。所以,你说共产党有没有信仰?

 

在哲学的世界里,信仰是做为一种非理性素而存在的。非理性因素具有动力、诱导、激发的作用,可以弥补逻辑思维的不足、激发人的创造能力,为人们带来强大的动力。所以说一个有信仰的人或团队,是非凡的,是拥有难以想像的力量的,在困难面前是不会低头的。如果一个人优柔寡断,迎难而退,那么他就没有自己的路,没有自己的主义,也就谈不上什么信仰!这种人或团队显然就是靠不住的!

 

路选对了,就不要怕远——这就是信仰!

03
Oct
2012

骑行苏州

标签: 骑行

阅读全文>>

21
Nov
2011

MY BOOK--Refactoring Patterns

标签: 重构
07
May
2011

背着自行车爬山……

标签: 骑行
03
Oct
2010

细说用例图中的关系

UML的用例图(Usecase Diagram)是一种很好的捕获需求的方法(比起古老的CRC),但在实际运用中却很少有人 真正能正确地使用它们。这次我要讲的是用例图中include、extend、generalizaion与association四种常见关系的用法......

阅读全文>>

02
Sep
2010

使用Command与Factory模式消除业务代码中的if,else语句

商业软件的一个特点就是拥有众多的业务逻辑,在进行一次操作时都会检查若干业务约束(如是否已登录等)。一般的方式就是采用 大量的if+else进行判断。

if (condition) {
    // do something
    return false;
} else if (condition) {
    // do something
    return false;
} else if ...
return true;

这样的问题在于,代码非常庞大,且难于理解,更不要谈复用了。这里我介绍一种采用Command与Factory模式的解决方案。

首先介绍一下我的设计,UML Class Diagram如下:

屏幕截图 2023-11-02 143358.png

首先应该注意的是,每个业务约束(Constraint,以下简称C)都对应一个对应的处理(Handle,以下简称H),我把它们称为业务约束单元,所有业务约束单元共同构成了一个约束集 A={{C1,H1},{C2,H2}....},这样,对次对一个业务操作的限制判断使变成一个有序集的遍历过程,形象地说,就像一个pipeline,每个业务约束也就是里面的valve,只要一个valve失败,就不能达到终点 执行相应的业务操作,同时还要执行对应的H。因此,上面中你能看见名为“*pipeline”和“*valve”的类,它们就是对应的集与单元。

但是每种约束单元都有自己固有的C与H,需要进行动态方法调用,这里我使用了Command模式(实际上就是利用了OO的多态性), 在图中可以看见名为BizCrstValve的接口(Interface)与其下属的实现方式,也就是说,程序只管调用BizCrstValve里的canPass与doHandle方法,具体怎么实现,是由接口的实现类来确定的,程序要做的就是像 接口发送一个命令而已(就是为什么叫Command模式的原因)。这样,我们可以把所的valve都存在一个List里面,然后对其遍历,调用每个valve的canPass与doHandle命令,如果某一个valve的canPass返回 为false,则执行它的doHandle命令。

public Result perform() {
  for (BizCsrtValve valve : valves) {
   if (!valve.canPass(params)) {
    return valve.doHandle(params);
   }
  }
  return new Result(true);
}
随着valves的遍历,业务约束还在一个一个地查检,一但有一个业务逻辑失败,对应的操作就会激活。

这里再说一下 BizCrstTypeEnum,由于我们已经将一个业务约束的C与其H封闭在一个 valve 中,那么它们完全就是高度可复用的了,因此, 可以给每个 valve 对应一杖举变量,这种我们就可以通过枚举变量来获得对应的 valve 了。如下:
BizCsrtTypeEnum.GOLD_USER_ONLY.getValve();
每个valve有自身的检测与处理机制,如下:
@Override
 public boolean canPass(Map<string, object=""> params) {
  try {
   int userID = (Integer) params.get(GoldUserOnlyValve.PARAM_USER_ID);
   if (userID == 12)
    return true;
   else
    return false;
  } catch (Exception e) {
   return false;
  }
 }
 @Override
 public Result doHandle(Map<string, object=""> params) {
  Result rs = new Result(false);
  rs.setBlockedValveType(BizCsrtTypeEnum.GOLD_USER_ONLY);
  
  return rs;
 }
在这里,枚举变量还有另外一个作用,那就是显示valve的错误信息,一个业务约束失败了我们总得给用户一个原因吧。

好了,现在还存在一个问题,那就是有线约束的H需要参数,而且,可能存在这么一种情况,那就是几个约束可能使用相同的参数, 如果每次都交给约束自己去生成的话,那岂不是太浪费了?明明可以复用的嘛。那我的方案就是在遍历所有valve前将所有valve需要的参数放入到一个map里面(你要调用你自己知道,你理所当然知道所有valve 需要哪些参数)。问题在于每个valve如何从map里面取出自己想要的参数?这里我认为,每个valve最了解自己需要什么参数,因此,每个valve有责任告诉调用着自己需要什么参数,正因为此,你才能在上面的 UML图里看见GoldUserOnlyValve这个类中存在一个PARAM_USER_ID的static变量,它表示这个valve需要一个名为user Id的变量,要使用“userID”来进行映射,如下

params.put(GoldUserOnlyValve.PARAM_USER_ID, 11);

在类图里还有一个名为Result的类,他的作用是存储一些valve失败时的信息,里面有个map,目前没有什么作用。

最后,总的流程如下:

屏幕截图 2023-11-02 144028.png

现在,你再也不用写文章开头的那种代码了,只需要:


BizCsrtPipleline bp = new BizCsrtPipleline(params, BizCsrtTypeEnum.NEED_LOGIN.getValve(),
    BizCsrtTypeEnum.GOLD_USER_ONLY.getValve());
  Result result = bp.perform();
valve的添加顺序就是你的约束检测的顺序,现在是不是清爽了许多?

«... 4 5 6 7 8 9 10