闹了一段时间的病毒疹,在医院里休息了7天。今天总算康复出院了。本来应该再休息一段时间,但是工作不会因为我休息而减少,而且我觉得我已经休息够了,那么明天就回去上班吧。 阅读全文…
1982年9月19日,美国卡耐基-梅隆大学的斯科特-法尔曼教授在电子公告板,第一次输入了这样一串ASCII字符:“:-)”。人类历史上第一张电脑笑脸就此诞生。从此,网络表情符号在互联网世界风行,为社会广泛接受。 阅读全文…
看看上篇日志的时间,才发现已经很久很久没写日志了。时间长到,我甚至有时都想不起来这里了。
最近一直在忙,忙新公司的组建,忙新系统的建设,忙新领导的心情,等等等等。今年的夏天来得好像很晚,也很短。刚刚有了些夏天的样子,没有持续多久,白露过后,一场秋雨扫过,就没有了以往的势头。
大上个周五搬到了新的办公室,然后就是接踵而至的工作工作和工作。
最近开始重新看数据结构。孔老先生说,温故而知新,可以为师矣。孔老先生神就神在这,两千多年前说的话了,到今天仍能与时俱进!
现在在看的数据结构,是java版。程序都是用java实现的了。和C的感觉真是太不一样了,或许我已经阔别C很久很久了吧。看来看去,还是java亲切些。
以1~5的倒序排列为例,在这放个java的堆栈,用数组实现,算是补白吧。
//—–Class NumStack——-
class NumStack
{
private int size;
private int[] stack;
private int top;
//—-建立一个栈
public NumStack (int length) {
size = length;
stack = new int[length];
top = -1;
}
//—-压栈
public void pushInto (int value) {
stack[++top] = value;
}
//—-出栈
public int getOutOf () {
return stack[top--];
}
//—-显示当前栈内最定端的值
public int displayTop () {
return stack[top];
}
//—-判断该栈是否为空
public boolean empty() {
retrun (stack[top] == -1);
}
//—-判断该栈是否已满
public boolean full() {
retrun (stack[top] == size-1);
}
}
//——–NumStackUser.java———
//这个类作为刚才容易的用户
class NumStackUser {
public static void main(String args[]) {
NumStack ns = new NumStack(5);
ns.pushInto(1);
ns.pushInto(2);
ns.pushInto(3);
ns.pushInto(4);
ns.pushInto(5);
while(!ns.Empty())
{
System.out.println(ns.getOutOf());
}
}
}
作者: 兼听则明 出处: java博客 责任编辑: 方舟 [ 2006-01-20 10:47 ]
公孙龙,六国时辩士也。疾名实之散乱,因资材之所长,为“守白”之论。假物取譬,以“守白”辩,谓白马为非马也。
以马作为进行问题域进行建模,已知存在白马这种类型。显然存在马的超类,并且马类包含一个属性-颜色,是否需要建立白马的子类呢?显而易见的是,当马的颜色属性是白色时,马的一些实例表达了一个白马的特殊实例群(由此我们可以得知:白马显然是马),根据里氏替换原则,子类型必须能够替换掉它们的基类型,显然在分析了马的行为模式以后,我们可以得出结论:白马可以替换马。----!难道真的要建立白马、黑马、X马的子类吗?
我认为可以从以下几方面进行分析。
1、类的职责(很大程度上等同于服务能力,操作方式):
设计一个类,首先要从类职责的分析入手,一个类要承担响应的职责,反过来说同样的职责应该由同样的类承担,否则会造成类泛滥,实例孤单的状况。如果领域内马和白马承担同样的职责,应该只建立马一个类,不应该只见树不见林,造成不抽象的类的产生。
2、类的行为模式(当类承担响应职责时,如何扩展):
分析一个类要从类的行为模式入手,既然一个类要承担责任,其承担的责任表现方式是否一样呢呢?这就是她的行为模式,这也是里氏替换原则主要起作用的地方,如果两个类的职责相当,但行为模式不同则不能成为超类和子类的关系(比如”著名”的正方形不是长方形问题)。马类,作为超类,基于一些特殊的行为方式:吃草,跑…,对于白马她的行为模式和马是一样的,并没有不同,所以白马是马而非马的同根继承子类。对于长方形和正方形都是具有相同计算面积算法(职责)的四方形的子类。
-------以下是关于此事的一些扩展分析-----------
3、子类的产生:
何时需要产生子类呢:是对其父类的职责进行扩展,白马没有对父类的职责进行扩展,所以不是马的子类。首先子类要扩展超类,其次子类不能重写或废除超类的职责。
4、属性,状态的区别(类的域)
对于一些类,在状态不同时,会有不同的表现(状态机模式),所以,类的getter,setter的部分包含两种不同的特性,对于属于状态的部分,是我们要仔细分析的,而”白”马则属于属性类(非状态)的域, 一般来讲,一个类的实例要能提供相应的差异服务(由于状态不同)最好使用不变模式[生存周期状态不变]或状态机[生存周期有状态,但状态不由调用者控制]来实现。
5、抽象类和接口
由于java的单根继承特性,很多设计人员不敢定义抽象类为继承树根,一定要先定义马的接口,在建立抽象马,作为一种”准规范”无可厚非,但我认为这是不愿承担责任的表现,有行为的基类应该可以(必须?)从类定义开始,避免白马类(一旦马成为接口,白马的产生就更加”名正言顺”了)的出现.将来如果发生变化可以通过重构(导出接口和使用委托),解决问题。
6、对象的创建(组装)和使用应该分开
既然对象的状态如此重要,属性有有很大程度的不变性(白马在构造时就用该是白的,并且一生不变),而骑马的人不必要求马的属性(!),所以,我们应该将马的构造和使用分开,使领域模型更清晰。使用一些Ioc容器,比如Spring就能很好的解决这些问题。
7、分析问题的领域
说了这么多,有一个问题;如果有一个马的研究机构,专门对不同颜色的马进行专题研究,马的颜色可能会对马的行为有很大影响,例如战马如果是黄色(绿色,哈哈)更利于伪装,此时”白”可能是一个很关键的问题,颜色会影响到不同的伪装策略,此时将白马作为马的一个子类则是必须的!所以问题域不同,类的设计就不同,生活中的问题域比较清晰(生物学家和厨师对马的理解不同),而软件建模时往往问题域混杂,这也是OO设计时比较困难的问题,所以分析问题域也是非常重要的设计问题。
翻看日历,已经有一个月的时间没有博了。我的博客是真正自己的博客,用来记录或转载一些经验,供那些如我般同样需要它们的人参考。比如我觉得以后我会用得上的资料,一些或直接或间接的经验。经验也是一种资源,通过互联网对彼此的经验进行交互,从而达到全民共建互联网的目的,我想,这就是博客初衷和用意吧。
但是感觉博客一词目前得到了充分的扩展。博客已经不仅仅是在web上来记录log,更多的人喜欢将博客向着diary的方向发展。我的很多朋友也都建立的自己的博客,我感觉轮经验的总结和交流,xiaorui的MSN空间算是一个相当正统的地方了。其实是weblog也好,diaryOnline也罢,无论人们怎么去理解博客,如何建立自己的博客,重要的一点,博客是一个代表,成为我们构建知识的一个索引,当我们谈及博客,也就想到了互联网,进而想到互联网产业,等等等等。于是,“互联网充分地影响人们的生活内容,改变人们的生活方式”,这一论点得到了充分的证明。
其实这本身就是一个不争的事实,即使我不写这些,也不会有人去怀疑。但恐怕说到名人,以及娱乐圈的博客们,那就有一些意思了。
再次回到博客的概念上来。不要去严格的定义,只去随便想想它的存在就好。
在娱乐圈,博客意味着什么?对于名人们而言,博客又意味着什么。我不知道格林斯潘、蒙代尔和索罗斯有没有自己的博客。如果有,可如果记录的只是些如“今天领小孙子去逛公园了”之类的日记,那真是很有意思了。所以我感觉并不是不可以有,而是他们敢写么?他们的言论关系到经济的动荡,如果有一天,新闻里报道说,根据某某经济学家博客中的一篇文章,美国原油期货价格跌破多少多少。呵~
但我感觉那样也好,至少信息的渠道缩短了,传播速度也加快了。可单纯就娱乐圈而言,这个行业果然最不缺少的就是炒作。star们都欣欣然地开通了自己的博客,然后有的在上面大放厥词,有的贴两张图片,也有的请人代写,娱乐圈的博客就和其本身一样,五光十色、五彩缤纷。可这又让我怀疑了,他们在博客里说的都是真的么?我一直以为他们的言论是很不自由的,动辄就遭到媒体的曝光或者批评,他们也敢如我的那位朋友一样坦荡地在属于自己的一亩三分地里宣泄自己的压力和情感么?如果不是,那博客又是为了什么呢?难道是为Fans们服务,贴近Fans与他们的距离?
为什么那么多的star都选择了同一家博客提供商呢?我不觉得star们的博客地址有多么好记啊。是他们的协会统一给他们开通的呢?还是彼此奔走相告呢?是什么都无所谓,总之sina这次打得算是漂亮了。而如果其他的博客提供商在sina之前更早地提出构想,那就是另一个时间轴线上发生的事情了。而专营娱乐信息的iFenSi.com也没有抢到这个契机,否则他们定会少发展好几年的,我很为他们感觉可惜。
互联网啊,就是这样,机会很多,但人们仍争先恐后地瓜分。残忍!
天气预报果然应验了。大连今天下了一天的雪,报纸上也登出了“雪灾黄色预警”这样的字样。自去年错过了那场五十年不遇的大学,今天的这场雪是我久等了的。
晚上吃完饭和父亲拿了相机出去,其实这是我第一次实实在在地拍摄夜间的雪景。路灯的光比较柔和,但映在雪上又反射回来,就比平常亮了许多,即使是夜景,快门也没有调得过分地慢。对比了几次,感觉快门在1/13,光圈在F3.2,距离路灯较近的景物就还好了,颜色还算是柔和。因为不喜欢用闪光灯,所以大多把闪光灯关掉了。
晚上很冷,所以拍得也比较仓促了。回来以后没有经过什么处理就放上来了。就是想让朋友们看看大连这次的雪景和规模。还算是原汁的吧。算不上是作品,所以感觉“写实”这两个字还算是贴切。还请朋友们多多批评。
曾经由于磁盘空间的问题,卸载了SQL Server2000,可当再次要把它安装上的时候,却怎么也不行了。无论是安装哪一个版本,永远都是同样的错误提示,说是有一个文件已经挂起,必须重新启动计算机。那okay啦,重新启动,再次安装,但是仍然是同样的问题。即使进入安全模式也没有用!
后来得知是注册表键值的问题,但是找不到具体是哪个。后来请教了。阿波罗同学,得以解决!只要删除\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\下的PendingFileRenameOperations键值,就可以重新安装了。
如果删除后仍然没有解决,就再删除一次吧。我当时安装的时候就删除了两次。当然了,删除后安装,是不必重新启动计算机的!
再过几分钟,就是2006年了。那听起来像是一个另人期待的时刻。2006年,我将在这一年结束我的学生时代,不再是一个消费者,而要转变成一个生产者了,要做一个对社会有意义的人了。 想了想,时间就这么匆匆地过去了。从1999年开始,我就喜欢在每年的这个时刻来记录些什么,然后找一个地方封存起来这些过往的回忆。但今年,在今天,我似乎不想写些什么总结之类的话语了。日子会越过越快的,所以早已经没有回头的空闲了。展望未来,希望未来会越来越好!总之,我的2005真的很精彩,生活又经历了很多新的事件,生命中又多了几个重要的角色,这一切的总总,我都会铭记在心,铭记我的2005,祝福与祈祷我的2006!
2006,我很期待。2006,祝愿自己实现人生的梦想!祝愿自己找到满意的工作!祝愿自己顺利毕业!祝愿自己健康、快乐、幸福!祝愿自己心想事成!祝愿家人都平安!祝愿朋友们都顺心!祝愿祖国风调雨顺国泰民安!祝愿所有老百姓都能笑口常开!祝愿张琪创业成功!祝愿慧慧顺利升本!祝愿为子工作顺利!祝愿飞迈入SAP!祝愿宋琦和罗兮都有好结果!祝愿东子永远这么快乐!祝愿宁子永远健康!祝愿小龙考研成功!祝愿小志开家大公司当大老板!…… 呵呵,朋友太多了,还是祝朋友们顺利吧! 祝福这个世界上所有美好事物永远美好!
2005就要结束了。真的没有一个很好的总结。经历了最郁闷的生日和最郁闷的圣诞,我想,我已经百毒不侵了吧。
2005的圣诞节, 还是我,还是《Say Forever》。
最近评论