语源科技BlogJava-zhrb的空间

jEdit的一些常用设置

zhrb — Tue, 02 Mar 2010 14:49:00 GMT

jEdit，一款用java编写的代码编辑器，可定制性很强，还有功能丰富的插件。
官方网址：   http://www.jedit.org/
先上一个官方网站其他人配置的图片吧。然后随便写一些前阵子折腾出来的常用设置

常用设置
    Utilities--Global Options
        Appearance(设置外观，其中Swing look $ feel如果设置成Metal风格，可以更改菜单等字体大小)
        Docking(设置插件、组件在编辑器中出现的位置，一般将FileBrowser设置在left，将console与Errolist设置在bottom)
        Editing(Tab witdh设置tab的空格数,Indent width设置缩进的空格数，Soft(emulated with space)tabs用空格模拟tab)
        Gutter(编辑区左边条状区域)
            1.Line numbers(显示行号)，Gutter font
        Text Area(编辑区)
            1.Text font(字体大小)
        View
            1.Show full path of buffer in title bar(在标题栏显示打开文件的完整路径)
            2.show buffer switcher(buffer switcher，打开文件切换器)
        File System Browser
            1.Default path(打开browser时默认打开的目录)
        Plugin Manager
            1.Update mirror list(插件升级服务器镜像列表)
            2.Install plugins in
                jEdit setting directory(jEdit设置目录，在windows操作系统下通常是在MyDocument目录下的 .jedit 目录)
                jEdit application directory(jEdit程序目录)

jEdit的设置目录(.jedit)
    存放jEdit设置、插件的目录（可以备份此文件夹来保存自己的设置与插件）位置（在windows操作系统下通常
是在MyDocument目录下的 .jedit 目录，也可以通过菜单Utilities--TroubleShooting--Activity log查看含有 message字
样的信息，一般包含.jedit的信息就是jEdit的设置目录）

常用插件及设置
    Plugins--plugin manager
        Install下可以选择想要安装的插件
        常用的插件
            console(控制台)
            error list(错误列表)
            buffer tab(以标签页的方式显示打开文件)
            code book(代码自动完成)
            java style(修饰代码风格)
            javainsight(反编译)
    插件不仅需要安装还需要设置，选择plugin options
    常用设置
        console(general下选择字体大小。Character encoding选择编码，请选择GBK，否则无法显示中文。Compile & run，选择编程语言对应的编译器等)
        buffer tabs(选择Enable BufferTabs by default)

先写这么多比较基础的设置，还有更多强大功能还有待挖掘。嘿嘿

zhrb 2010-03-02 22:49 发表评论

用UML做好系统分析(转载)

zhrb — Wed, 25 Jun 2008 15:06:00 GMT

原帖地址：
http://www.infoq.com/cn/articles/use-uml-to-do-system-analysis

业务很重要...呵呵

zhrb 2008-06-25 23:06 发表评论

转载：奥卡姆剃刀

zhrb — Wed, 25 Jun 2008 15:03:00 GMT

转载：奥卡姆剃刀

发表于：2008年6月25日 22时59分0秒评论(1) 举报本文链接：http://user.qzone.qq.com/2882888/blog/1214405940

发信人: Vulcain (龙★火神), 信区: Philosophy
标  题: 转载：奥卡姆剃刀
发信站: 水木社区 (Wed Jun 25 22:48:38 2008), 站内
Phil Gibbs 著　
杉原广补充
柯南　译  　
　　奥卡姆剃刀（Occam's Razor, Ockham's Razor）是由14世纪逻辑学家、圣方济各会修
士奥卡姆的威廉（William of Occam）提出的一个原理。奥卡姆（Ockham）在英格兰的萨里郡，那是他出生的地方。
　　这个原理称为“如无必要，勿增实体”（Entities should not be multiplied
unnecessarily）。
    威廉使用这个原理证明了许多结论，包括“通过思辨不能得出上帝存在的结论”。这使他不受罗马教皇的欢迎。　　许多科学家接受或者（独立的）提出了奥卡姆剃刀原理，例如莱布尼兹的“不可观测事物的同一性原理”和牛顿提出的一个原则：如果某一原因既真又足以解释自然事物的特性，则我们不应当接受比这更多的原因。
　　对于科学家，这一原理最常见的形式是：
　　当你有两个处于竞争地位的理论能得出同样的结论，那么简单的那个更好。
　　在物理学中我们使用奥卡姆剃刀切掉形而上学的概念。爱因斯坦的狭义相对论与洛仑兹
的理论就是一个范例。洛仑兹的理论认为在以太中运动的尺收缩、钟变慢。爱因斯坦关于空—时变换的方程与洛仑兹方程在钟慢尺短效应上一致，但是爱因斯坦和庞加莱（法国数学家——译注）认为以太不能根据洛仑兹和麦克斯韦方程组检测到。根据奥卡姆剃刀，以太就被排除了。
　　这一原理也被用来证明量子力学的不确定性。海森堡从光的量子本性和测量效应中推出了不确定原理。
　　史蒂芬·霍金在他的《时间简史》中解释说：我们仍然可以想像，对于一些超自然的生物，存在一组完全地决定事件的定律，它们能够观测宇宙现在的状态而不必干扰它。然而，我们人类对于这样的宇宙模型并没有太大的兴趣。看来，最好是采用称为奥卡姆剃刀的原理，将理论中不能被观测到的所有特征都割除掉。
　　但是“不能确定以太的存在”和“以太的不存在”都不能仅仅根据奥卡姆剃刀推出。它可以区分两个能做出同样结论的理论，但是不能区分其他可能做出不同结论的理论。实验的证据仍然是必需的，并且奥卡姆本人支持经验主义，而不是反对。
　　厄恩斯特·马赫提倡奥卡姆剃刀的一个版本，他称作“经济原理”，表述为：“科学家应该使用最简单的手段达到他们的结论，并排除一切不能被认识到的事物”。把它引入哲学就形成了实证主义哲学，即认为某物存在但无法观测与根本不存在是一码事。马赫影响了爱因斯坦关于时空不是绝对的论述，但是他（马赫）也把实证主义应用到分子的概念。马赫和他的追随者认为分子是形而上学的概念，因为它们太小而不能被直接探测到。这种主张不顾分子论在解释化学反应和热力学上的成功。具有讽刺意味的是，当使用经济原理抛弃了以太和绝对参照系的时候，爱因斯坦几乎同时发表了一篇关于布朗运动的论文，它证实了分子的实在性，这就打击了实证主义的使用。这个故事意味着，我们不能盲目使用奥卡姆剃刀。正如爱因斯坦在他的《自传笔记》中写道：
　　即使是大胆而天才的学者也会因为哲学上的偏见而妨碍他认清事实，这是一个很有趣的例子。
　　人们常常引用奥卡姆剃刀的一个强形式，叙述如下：
　　如果你有两个原理，它们都能解释观测到的事实，那么你应该使用简单的那个，直到发现更多的证据。
　　对于现象最简单的解释往往比较复杂的解释更正确。
　　如果你有两个类似的解决方案，选择最简单的。
　　需要最少假设的解释最有可能是正确的。
　　……或者以这种自我肯定的形式出现：
　　让事情保持简单！
　　注意到这个原理是如何在上述形式中被加强的。严格的说，它们应该被称为吝啬定律，或者称为朴素原则。最开始的时候我们使用奥卡姆剃刀区分能够做出相似结论的理论。现在我们试图选择做出不同结论的理论。这不是奥卡姆剃刀的本意。我们不用检验这些结论吗？显然最终不是这样，除非我们处于理论的早期阶段，并且还没有为实验做好准备。我们只是为理论的发展寻求一种指导。
　　这个原理最早至少能追溯到亚里士多德的“自然界选择最短的道路”。亚里士多德在相信实验和观测并无必要上走得太远。朴素原理是一个启发式的经验规则，但是有些人引用它，仿佛它是一条物理学公理。它不是。它在哲学和粒子物理中使用的很好，但是在宇宙学和心理学中就不是特别好，这些领域中的事务往往比你想象的还要复杂。或许引用莎士比亚的一句话要胜过引用奥卡姆剃刀：“天地之大, 赫瑞修, 比你所能梦想到的多出更多”（出自《哈姆雷特》，第一幕，第五景——译注）
　　朴素是主观的，宇宙并不总是像我们认为的那样简单。成功的理论往往涉及到对称、美与简单。1939年保罗·狄拉克写道：
　　研究者在把自然法则转变为数学形式的时候，应该为数学的美而努力。对于简单和美的需求往往是等价的，然而当它们发生冲突的时候，后者应该优先。
　　吝啬原理不能取代洞察力、逻辑和科学方法。永远也不能依靠它创造或者维护一个理论。作为正确性的判别方法，只有逻辑上的连贯性和实验的证据才是绝对的。狄拉克的理论很成功，他构造了电子的相对论场方程，并用它预言了正电子。但是他并没有主张物理学仅仅应该基于数学的美。他完全赞同实验检验的必要性。
　　最后的结论来自爱因斯坦，他本身也是一位格言大师。他警告说：
　　“万事万物应该尽量简单，而不是更简单。”　
--
如果我们仔细的研究唐诗宋词，就会发现里面有全部已知和未知的现代数学和物理学定理。现在我确知李卫公所写的春宫解说词里包含了费尔马定理的证明，但我没法把它读出来——这是因为费尔马定理的证明应该是怎样的，现在没有人知道，或者说，现在还没有人能够证出费尔马定理。它就如隋时发明的避孕套，到唐代就失传了，因此给了洋鬼子机会，让他们可以再发明一次。因为它已经失传，所以我也不知该怎样解释这些说明词。最简单的解释是：那是一些性交的诀窍。但是不应该是这样子的。不应该的原因是有我们存在。我们的任务就是把性交的诀窍解释成数学定理，在宋词里找出相对论，在唐诗里找出牛顿力学。——王小波《红拂夜奔》
※ 来源:·水木社区 http://newsmth.net·[FROM: 210.78.58.*]

zhrb 2008-06-25 23:03 发表评论

zz做JAVA开发要掌握的知识

zhrb — Mon, 02 Jun 2008 04:01:00 GMT

发信人: kabbesy (Arthas), 信区: Java
标题: zz做JAVA开发要掌握的知识
发信站: 水木社区 (Sun Jun 1 23:42:19 2008), 站内

http://www.javaeye.com/topic/183513

来自http://www.bjsxt.com/zixue/zixuezhilu_1.html

一：J2SE
面向对象－封装、继承、多态
内存的分析
递归
集合类、泛型、自动打包与解包、Annotation
IO
多线程、线程同步
TCP/UDP
AWT、事件模型、匿名类
正则表达式
反射机制

2：数据库（Oracle或者MySQL）
SQL语句
多表连接，内外连接，子查询等
管理表、视图、索引、序列、约束等
树状结构存储
存储过程、触发器
数据库设计三范式、

3：JDBC
JDBC基础
连接池
树状结构存储与展现
DataSource & RowSet
JDBC连接Oracle及MySQL

4：HTML_CSS_JAVASCRIPT
html、css、javascript基础语法
JavaScript Form判断
Dom编程基础（事件处理等）
JS常用效果如TreeView、下拉联动等
JS学习方法
JS调试方法
DreamWeaver初步（建立HTML、Table、Form、CSS）等

5：Servlet & JSP

tomcat基础
servlet基础
web.xml配置基础
web application的结构
servlet生命周期
request response等常用方法
ServletContext类
HTTP协议基础（GET POST）
Cookie
Session
Application

JSP的几种语法（包括JSTL等）注意在项目中练习，不要拘泥于语法细节而裹步不前。

6：Struts
多层架构理论
Model 1 and Model 2
Struts基本概念
MVC
Action与业务逻辑类的关系
在Struts与JSP之间传递数据
Struts处理流程（控制流）
Struts TagLib（了解常用的）
JSTL
ActionForm
字段收集
上传文件
类型转换
DTO
动态Action Form
验证框架
ActionForward 转发与重定向
动态生成ActionForward
全局与局部的ActionForward
Action Forward Scope
UnknownActionMapping
Action的线程安全
I18N
如何切换语言环境
Struts异常处理机制程序处理自动处理自定义异常处理器
Struts的多模块配置

7：XML
（XML/XSL、XSLT/DTD、SCHEMA等基础的概念、关于Java的编程可以暂时扔在一边）

8：Hibernate
OR Mapping原理
Hibernate基础开发步骤
Hibernate基本接口（重点Session）
普通属性映射
关联关系映射
Native SQL
inverse lazy cascade
继承关系映射
HQL
性能优化一级缓存二级缓存查询缓存
事务与并发悲观锁、乐观锁
OpenSessionInView
CurrentSession
（至于JTA、联合主键、自然主键、动态主键、Any类型 Creteria Queries Intercepter and Event 自定义类型等，可以暂时扔在一边）

9：Spring
IOC/DI
Spring配置
Spring架构
AOP及Spring AOP
声明式事务（AOP）
Spring + Hibernate Spring支持Web
Scope
（其他的Spring模块对于自学来说可以暂时扔在一边）

10：EJB3.0
J2EE架构基础（JTA JMS等）
EJB基础（地位及基本理论、分类等）
Annotation
Ant编译与部署EJB
Session Bean
EJB的依赖注入
Persistence API
（可以用JBoss学习EJB3.0）

11:至于SOA，对于自学的同学来说，暂时不用特别关注。

梳理一下，你就会发现东西不是想象中的那么多呀！

--
The pact is sealed!

※ 来源:·水木社区 newsmth.net·[FROM: 125.33.176.*]

zhrb 2008-06-02 12:01 发表评论

用lucene建立简单的索引软件的一个需求

zhrb — Mon, 12 May 2008 13:33:00 GMT

应用lucene建立简单的索引软件
可以使用lucene进行程序的编写

发信人: minos (卡妙), 信区: NewSoftware
标题: 有什么软件能够为office文档建立索引目录？
发信站: 水木社区 (Mon May 12 11:16:28 2008), 站内

就如同word的索引，它是为word里面的文字建立索引。

能有个方便的软件能为doc,ppt,xls文档建立索引，并添加注释就好了

zhrb 2008-05-12 21:33 发表评论

任务分发系统

zhrb — Sat, 19 Apr 2008 16:54:00 GMT

主要功能：为用户群建立群组，群组中含有任务分发与管理、论坛、发放通知、资源共享（照片、文件等）。每个用户都有自己的信息中心，里面包含任务、信息、个人功能。成熟以后，可以为用户开发相应的客户端，类似qq。其实本质上就是开发一个个人信息中心。

可能涉及的难点：权限管理、任务分排与管理

以后的工作：C/S

自己随便的一个想法，不知道国内有没有已经做得很成熟的系统可供参照，希望大家可以帮忙介绍一下。呵呵

zhrb 2008-04-20 00:54 发表评论

填坑：oo的前世今生及后世(zz)

zhrb — Sat, 19 Apr 2008 02:34:00 GMT

发信人: gentboy (老流氓，老水车，老男人就是快乐的一家), 信区: Java
标题: 填坑：oo的前世今生及后世
发信站: 水木社区 (Fri Apr 18 13:27:06 2008), 站内

摘要：需求一直在扩展，逻辑复杂度以更高的速度增加，而人的逻辑处理能力没有任何变?
。oo解决了一个stage的问题，但是类似于软件危机的问题肯定还会出现，期待新的逻辑或
者工具来解决这个问题。

N多年前，软件危机的出现基于三个事实，一个是需求迅速增长，功能要求越来越多；再者软件的复杂度并不是与软件的体积成正比的，复杂度的增长速度要远大于代码的行数的增长速度。

还有一个没有被强调的原因就是，人的能力是有限的，对于复杂的软件，没有任何一个人能掌握所有的逻辑，即使他了解所有的逻辑，也不可能同时考虑到这些逻辑。因此，人们在编写软件时，只能在有限的视野内工作，这种情况本身就决定了软件中的缺陷难以避免。

oo被认为是解决软件危机一个比较好的方法，主要原因就是oo将整个软件中的大量逻辑和数据封装起来，从而使得程序员不必关注所有的细节，而只关注与自己负责的部分有关的细节。这大大减轻了程序员的负担，从而也使软件规模得到了较大的扩大。

但是，需求仍在继续增长，而且逻辑的复杂度又以更快的速度增长。用oo编程的程序员们渐渐感觉到即使大量的逻辑被封装了，剩下的要处理的逻辑仍然足够复杂。

而且，oo也是一把双刃剑，如果封装的方法不当，同样会给别人的开发造成麻烦。而且不同的程序员往往对同一个应用有着不同的理解。这使得协作中的冲突很常见。

因此大量的针对具体应用的framework出现了，比如orm, ejb, struts等等，这些framework从某种程度上定义了某种具体应用的范式，把应用中有共性的部分拿出来，而让程序员做那些有特性的东西。这又让程序员少考虑了不少东西。

到目前为止，framework的确起了不小的作用，也出现了很多超大型的framework，能让程序员写很少的代码就能完成原来可能要18个人干半年才能完成的任务。

但是，framework也有其本身的缺陷，一个是framework往往本身就足够复杂，难以学习已经是一些大型的framework的通病。另外framework本身也有质量问题，过分依赖或者不正确的使用framework的后果同样是致命的。

framework替你做的事情越多，程序员往往就越难以使用它，但是如果他做的东西少，程序员就会喊自己做了很多重复劳动。因此这两者之间要有一个平衡。从这个角度来讲，spring做的比jboss要好。

展望将来，需求的规模还会继续增长，而逻辑的复杂度仍然会以相对于需求的复杂度的指数形式增长。但是人的脑子跟几十年前没什么区别，还是同时能处理那么多逻辑。尖锐问题肯定会出现。

但是解决问题的方法呢？单单靠语言特性恐怕已经难以再做什么。人们应当再次反思程序这个概念本身，提出新的解决方案。或许人们会开发出更为实用的framework以定义业务逻辑，更为智能化的集成开发/协作环境工具来扩展我们的大脑，或者其它...

--

晶晶姑娘是个好姑娘

※ 修改:·gentboy 于 Apr 18 13:28:32 2008 修改本文·[FROM: 210.13.85.*]
※ 来源:·水木社区 newsmth.net·[FROM: 210.13.85.*]

zhrb 2008-04-19 10:34 发表评论

技术是一种加速器但重要的不是技术(zz)

zhrb — Mon, 14 Apr 2008 11:31:00 GMT

发信人: NewXin (睡猫|糖果气泡), 信区: ITExpress
标题: 技术是一种加速器但重要的不是技术
发信站: 水木社区 (Mon Apr 14 12:32:38 2008), 站内

喷嚏网：原创 www.dapenti.com
（一）

多年以前，我有个学生在一家做“工作流引擎”的软件小公司里工作。他遇到了一些麻烦
。

什么是“工作流引擎”？简单地说，是一种可以自动执行流程的工作元件：使用者设置好
基本的参数，该元件就能按照预先设定的工作步骤和业务的流程往下走。

听起来很酷，看上去很美。

学生的麻烦是：公司的产品做得歪瓜劣枣的，开发人员不够，人员参差不齐。总的说来，
技术问题很多，公司也不太重视。

他来问我他该怎么办。

我说：其实，这不是技术的问题。而是在于以公司这样的实力进入这样的小众市场，完全
没有能力。高端的“工作流引擎”肯定有市场，但是都是很多IT的老大才做。中低端的应用
，需要的不是自动化软件，而是人事关系。这就更与技术无关。

技术是很好的想法，但是没有生根的地方。从商业和个人投资来看，就没有商业价值。

我给他的建议是：赶快离场，做点其他的。

（二）

我在软件行业做过10年以上的技术工作。我知道技术人员在某一个阶段上会有一个通病，
就是：太把技术当回事儿。

怎么说呢？就是说总是从技术的观点去考虑问题，想到希望发生的事情，而不会从一个普
通人的角度看待现实。

理解技术是好事情，你可以飞快地想象到未来，看到一种趋势。但是，你一定要明白，这
种趋势可能发生，也可能只是一种错觉。

技术是一种加速器。但是你不知道，这是成功的加速器，还是速死的加速器。

技术的思维角度，如果放错了位置，很多时候，会成为认知上的障碍。你以为你看到的东
西是重要的，其实，人们根本不是按你想象的方式需要，或者生活。

技术是一种异化过程。当你以为你是专业人士的时候，你也有可能忘记：作为普通人，他
们的感觉应该是什么样子。

（三）

我经常在小区的周围散步。我看见各种各样的小商铺，开办的热火朝天。我最喜欢的是一
家小面馆。这些店铺的生意各不相同，但都有一个共同之处：跟我的职业没有任何的关系。也就是说，他们都是一些远离互联网的又小又好的生意。比如：洗衣店、蛋糕房、小型超市。

我很清楚，至少在我活着的时候，我还不能从网络上下载一碗面。这种想法，总是提醒我
注意在伟大的传统行业面前，保持谦卑。

看着很多2-3个人，10来个人开办的火热的小生意。我就在想：什么样的生意才算是好生意呢？能活着的生意，当然是好的。这些生意还应该有如下的特点：

【1】有广泛的需求，无认知障碍，应用的技能简单，如：吃饭、穿衣。这是谁都需要，谁都会的事情；

【2】市场庞大，不是只需几家就能搞定的，而且要方便。需求是有循环、反复的；

【3】满足需求的产品种类独特，或者丰富；

作为技术的互联网，是如何改变了传统的市场？

优势：

【1】技术跨越了地域的限制，信息加速，需求被聚合；

【2】信息流动得更快，用户间的接触增加，消费变得可以评价；

【3】营销的方式发生了根本的变化

劣势：

【1】信任成本的建立很高；

【2】商品的可接触成本很高；

【3】需求到消费的转换率不高；

这样看来，我们就很容易理解这样的事实：互联网上的生意看着人多，其实一点都不便宜
。而且，还不太容易存活。难怪那么多人，成天闹着要忽悠风投。

能自个赚钱了，还需要风投干嘛。

（四）

任何一个成功的互联网项目或产品，至少应该具有这样的基本特征：

【1】首先要是一个很好的生意。

上面说过了，无论是用月球的技术还是火星的技术，生意还是生意，生意的本质并没有改
变。

【2】要找到一个跟这种生意匹配的业务形式，或是商业模式：

扎堆，是人多。人多好办事，但是成本也高。而且，面越广，实质就越少。

任何一个商业系统都是中性系统，不可能是完美的系统。所以说，长尾是一种浪漫的说法
。对长尾的正确理解应该是：传统系统能做5个特性的话。长尾目前也最多能扩展到10或者
15。

如果首先有80/20的业务存在，那么互联网的长尾就会看上去非常优美。如果没有，长尾就等于是零。

所以，那些办起博客，相册就叫web 2.0的网站，肯定是：非死不可（FaceBook）。同时
，如果能符合上面的两个条件的社区或管它叫什么的网站，却会活得很好。

我相信基本的一点：当所有人谈论商业模式，谈钱的时候。他们都要回到最根本的问题上
--商业的需求从何而来，是怎么样的一个规模，在某个具体的平台下，技术能提供怎么样的突破，该如何提供什么样的产品和服务的形式来满足这些需求。

虽然有些社区是非死不可了，但我仍然看好这样的一类网站：婚恋市场，如世纪佳缘类的
，还有育儿市场，如宝宝树之类的。

这样的网站首先是有一个无限广阔的市场空间，而且网站的内容跟业务结合的非常紧密。
只要不犯大的错误，坚持下去，这样的业务本身不仅可以赚大钱，而且可以一直做很久。因为，很多业已存在的传统生意，被证明已经是好生意。

我一直认为：web 2.0类的网站发展，是电子商务普及的前哨战。很多的炮灰会成就电子商务的明天。我敢打赌：活下来的都是不太关心是2还是1的人。

最后，提一下作为web 2先驱的豆瓣：尽管?

如果首先有80/20的业务存在，那么互联网的长尾就会看上去非常优美。如果没有，长尾就等于是零。

虽然有些社区是非死不可了，但我仍然看好这样的一类网站：婚恋市场，如世纪佳缘类的
，还有育儿市场，如宝宝树之类的。

我一直认为：web 2.0类的网站发展，是电子商务普及的前哨战。很多的炮灰会成就电子商务的明天。我敢打赌：活下来的都是不太关心是2还是1的人。

最后，提一下作为web 2先驱的豆瓣：尽管开始人多势大了，也加了很多功能，但是，本身的特色也在丧失。豆瓣赋予了自己太多的使命。我觉得谦卑一点还是比较好。我喜欢作为读
书工具的豆瓣，而不太喜欢作为交友工具的豆瓣。一会儿是关注，一会儿又是好友。一会
儿是广播，一会儿又是日记。

如果功能太多，只能让人不知所措。面越广，实质就越少。

我最喜欢《玩具总动员》里面主人翁的第一句话：focus,speed!

我的理解是：专注，才有速度。

※ 来源:·水木社区 http://newsmth.net·[FROM: 202.108.130.*]

zhrb 2008-04-14 19:31 发表评论

面向对象的思维方法 [zz]

zhrb — Tue, 25 Mar 2008 09:26:00 GMT

发信人: seableu (地球是天上一颗星), 信区: JavaExpress
标题: 面向对象的思维方法 [zz]
发信站: BBS 水木清华站 (Sat Jan 8 20:02:47 2005), 站内

刚才看到一篇文章，是有关面向对象的思维方法的，感觉对我很有启发，贴出来大家一起看，呵呵。
原文链接：http://blog.csdn.net/wooaoo/archive/2004/07/30/56163.aspx

------------------------------------------------------------------------
面向对象的思维方法
作者：范凯
E-mail: robbin_fan@yahoo.com.cn

我是从学习Java编程开始接触OOP(面向对象编程)，刚开始使用Java编写程序的时候感觉很别扭，因为我早以习惯用C来编写程序，很欣赏C的简洁性和高效性，喜欢C简练而表达能力丰富的风格，特别忍受不了Java运行起来慢吞吞的速度，相对冗长的代码，而且一个很简单的事情，要写好多类，一个类调用一个类，心里的抵触情绪很强。

我对Java的面向对象的特性琢磨良久，自认为有所领悟，也开始有意识的运用OOP风格来写程序，然而还是经常会觉得不知道应该怎样提炼类，面对一个具体的问题的时候，会觉得脑子里千头万绪的，不知道怎么下手，一不小心，又会回到原来的思路上去。

举个例子，要发广告邮件，广告邮件列表存在数据库里面。倘若用C来写的话，一般会这样思考，先把邮件内容读入，然后连接数据库，循环取邮件地址，调用本机的qmail的sendmail命令发送。

然后考虑用Java来实现，既然是OOP，就不能什么代码都塞到main过程里面，于是就设计了三个类：

一个类是负责读取数据库，取邮件地址，调用qmail的sendmail命令发送；
一个类是读邮件内容，MIME编码成HTML格式的，再加上邮件头；
一个主类负责从命令读参数，处理命令行参数，调用发email的类。

把一件工作按照功能划分为3个模块分别处理，每个类完成一件模块任务。

仔细的分析一下，就会发现这样的设计完全是从程序员实现程序功能的角度来设计的，或者说，设计类的时候，是自低向上的，从机器的角度到现实世界的角度来分析问题的。因此在设计的时候，就已经把程序编程实现的细节都考虑进去了，企图从底层实现程序这样的出发点来达到满足现实世界的软件需求的目标。

这样的分析方法其实是不适用于Java这样面向对象的编程语言，因为，如果改用C语言，封装两个C函数，都会比Java实现起来轻松的多，逻辑上也清楚的多。

我觉得面向对象的精髓在于考虑问题的思路是从现实世界的人类思维习惯出发的，只要领会了这一点，就领会了面向对象的思维方法。

举一个非常简单的例子：假使现在需要写一个网页计数器，客户访问一次页面，网页计数器加1，计数器是这样来访问的

http://hostname/count.cgi?id=xxx

后台有一个数据库表，保存每个id（一个id对应一个被统计访问次数的页面）的计数器当前值，请求页面一次，对应id的计数器的字段加1(这里我们忽略并发更新数据库表，出现的表锁定的问题)。

如果按照一般从程序实现的角度来分析，我们会这样考虑：首先是从HTTP GET请求取到id，然后按照id查数据库表，获得某id对应的访问计数值，然后加1，更新数据库，最后向页面显示访问计数。

现在假设一个没有程序设计经验的人，他会怎样来思考这个问题的呢？他会提出什么样的需求呢？他很可能会这样想：

我需要有一个计数器，这个计数器应该有这样的功能，刷新一次页面，访问量就会加1，另外最好还有一个计数器清0的功能，当然计数器如果有一个可以设为任意值的功能的话，我就可以作弊了。

做为一个没有程序设计经验的人来说，他完全不会想到对数据库应该如何操作，对于HTTP变量该如何传递，他考虑问题的角度就是我有什么需求，我的业务逻辑是什么，软件应该有什么功能。

按照这样的思路(请注意，他的思路其实就是我们平时在生活中习惯的思维方式)，我们知道需要有一个计数器类 Counter，有一个必须的和两个可选的方法：

getCount() // 取计数器值方法
resetCounter() // 计数器清0方法
setCount() // 设计数器为相应的值方法

把Counter类完整的定义如下：

public class Counter {
public int getCount(int id) {}
public void resetCounter(int id) {}
public void setCount(int id, int currentCount) {}
}

解决问题的框架已经有了，来看一下如何使用Counter。在count.cgi里面调用Counter来计数，程序片断如下：

// 这里从HTTP环境里面取id值
...
Counter myCounter = new Counter(); // 获得计数器
int currentCount = myCounter.getCount(id); // 从计数器中取计数
// 这里向客户浏览器输出
...

程序的框架全都写好了，剩下的就是实现Counter类方法里面具体的代码了，此时才去考虑具体的程序语言实现的细节，比如，在getCount()方法里面访问数据库，更新计数值。

从上面的例子中看到，面向对象的思维方法其实就是我们在现实生活中习惯的思维方式，是从人类考虑问题的角度出发，把人类解决问题的思维方式逐步翻译成程序能够理解的思维方式的过程，在这个翻译的过程中，软件也就逐步被设计好了。

在运用面向对象的思维方法进行软件设计的过程中，最容易犯的错误就是开始分析的时候，就想到了程序代码实现的细节，因此封装的类完全是基于程序实现逻辑，而不是基于解决问题的业务逻辑。

学习JDBC编程的经典错误问法是：“我怎样封装对数据库的select操作？”

面向对象的设计是基于解决业务问题的设计，而不是基于具体编程技术的设计。我不会去封装select语句的，我只封装解决问题的业务逻辑，对数据库的读取是在业务逻辑的编码实现阶段才去考虑的问题。

回过头看上面那个发广告邮件的例子，应该如何应用面向对象的思维方法呢？

对于一个邮件来说，有邮件头，邮件体，和邮件地址这三个属性，发送邮件，需要一个发送的方法，另外还需要一个能把所有邮件地址列出来的方法。所以应该如下设计：

类JunkMail

属性：
head
body
address
方法：
sendMail() // 发送邮件
listAllMail() // 列邮件地址

用Java来表示：

public class JunkMail {
private String head;
private String body;
private String address;
public JunkMain() { // 默认的类构造器
// 从外部配置文件读邮件头和邮件体
this.head=...;
this.body=...;
}

public static boolean sendMail(String address) {
// 调用qmail，发送email
}

public static Collection listAllMail() {
// 访问数据库，返回一个邮件地址集合
}
}

当把JunkMail设计好了以后，再调用JunkMail类完成邮件的发送，将是非常轻松的事情。

如果说传统的面向过程的编程是符合机器运行指令的流程的话，那么面向对象的思维方法就是符合现实生活中人类解决问题的思维过程。

在面向对象的软件分析和设计的时候，要提醒自己，不要一上来就去想程序代码的实现，应该抛开具体编程语言的束缚，集中精力分析我们要实现的软件的业务逻辑，分析软件的业务流程，思考应该如何去描述和实现软件的业务。毕竟软件只是一个载体，业务才是我们真正要实现的目标。

但是在设计过程中，心里却往往在担心，如果我完全不去考虑程序代码的实现的话，那么我怎么知道我的设计一定合理呢？我怎么知道我设计的类、接口一定可以实现呢？（是个问题：（）所以经常可以看到的现象就是：

在设计过程中，虽然知道不能过早考虑代码实现，但是每设计一个类，一个接口，心里都要不知不觉的用自己熟悉的编程语言大概的评估一下，看看能否编出来，因此，一不小心，就会又回到按照程序功能实现的思路进行设计的老路上去了。

举个例子来说明，在做Web程序设计的时候，经常要遇到分页显示数据的情况。比如说需要把系统中所有的用户都列出来这样的功能。假设使用User类来表示用户，增加用户addUser()，删除用户deleteUser()，查询所有用户listUsers()方法。而数据库中有一个user表，一条记录是一个用户的信息。下面考虑一下User类的方法的实现：

addUser()和deleteUser()方法都好实现，就是对数据库增加记录和删除记录。对于listUsers()方法，其实就是对user表的select，取出一个记录集。但是该怎么从listUsers()方法中得到所有用户的列表呢？

一个方法调用的返回值只有一个，没有多个，所以很多情况下采用的办法就是返回值定义为集合类型，比如Vector。这样就可以在listUsers()方法的具体代码实现的时候，从数据库依次取出一个个记录，插入到Vector里面来。在主程序里面，调用listUsers()方法可以返回一个Vector，然后再对Vector遍历操作，就可以得到用户列表了。

public class User {

public static void addUser(...) {
// 数据库insert一条记录
}

public static void deleteUser(...) {
// 数据库delete一条记录
}

public Vector listUsers(...) {
// 数据库select结果放到一个集合里面
}
}

这样的设计基本合理，但是仍然有点小问题。因为在设计的时候，就考虑到了用Java的集合类Vector来实现对不定长数据集的存放，因而违反了面向对象设计的一个原则：在设计的时候不应过早的考虑具体程序语言的实现。所以必须用抽象的方法，和具体实现无关的方法来表达业务逻辑。

我们知道，通常对具有集合特征的数据结构进行遍历通常可以使用next和hasNext方法，next实现取下一个用户，hasNext判断是否还有元素。因此我们定义一个接口Iterator，这个接口中定义两个方法next和hasNext：

public interface Iterator {
public boolean hasNext() {}
public Object next() {}
}

而User类的listUses方法返回值改为Iterator接口的实现类:

public class User {
...
public Iterator listUsers() {
}
...
}

这样就把User类的设计和具体的实现方法分离开了，因为此时任何实现了next()和hasNext()方法的类都可以做为listUsers的返回值，都可以被用来表达“用户列表”，而不仅仅可以使用Vector而已。比如，我可以用ArrayList来表达用户列表，因为ArrayList也实现了Iterator，当然我也可以自己专门写一个类来存放用户列表，只要实现next()和hasNext()方法就行了。

这样在具体的编写代码的时候，程序员具有了最大的灵活性，可以根据具体的情况，采用不同的编程方法来存放用户列表。特别是降低了程序的耦合度，提高了程序的可移植性。对于上面那个JunkMail的listAllMail()方法也同样应该改为接口类型。

然后，在主程序里面就这样来使用User类的listUsers方法：

User myUser = new User();
Iterator iterator = myUser.listUsers();
while (iterator.hasNext()) {
iterator.next();
}

这样就可以完全不用考虑程序代码实现了，从高层次上把功能抽象出来，定义成为接口，同时又可以把系统设计的很合理，完全根据业务的需求来进行设计。

结语

通过上面的几个例子的设计说明，使用面向对象的思维方法，其实是一个把业务逻辑从具体的编程技术当中抽象出来的过程，而这个抽象的过程是自上而下的，非常符合人类的思维习惯，也就是先不考虑问题解决的细节，把问题的最主要的方面抽象成为一个简单的框架，集中精力思考如何解决主要矛盾，然后在解决问题的过程中，再把问题的细节分割成一个一个小问题，再专门去解决细节问题。

因而一旦牢牢的抓住了这一点，你就会发现在软件设计和开发过程中，你自己总是会不知不觉的运用面向对象的思维方法来设计和编写程序，并且程序的设计和开发也变得不再那么枯燥，而一个合理运用面向对象技术进行设计和架构的软件，更是具备了思维的艺术美感。

最后，愿面向对象的思维方法也能给您的程序设计之路带来创作的乐趣。

--
有一名年轻人名字叫seableu，
他的速度远胜于光，
一天，他启程旅行，
但却于前一天就返回了！

※ 来源:·BBS 水木清华站 http://smth.org·[FROM: 212.194.215.*]

zhrb 2008-03-25 17:26 发表评论

需求分析很重要很强大

zhrb — Tue, 18 Mar 2008 04:47:00 GMT

转某个大牛关于需求分析的一段评论：

发信人: zms (来福), 信区: Java
标题: Re: 这个怎么解决？
发信站: 水木社区 (Tue Mar 18 11:58:58 2008), 站内

这么解决:

1. 需求分析,把当前的需求搞清楚
2. 需求分析,把未来可能出现的需求搞清楚
3. 需求分析,把可能扩展以及发挥的需求搞清楚
4. 需求分析,预料可能出现的变态需求
5. 需求分析, 把以上需求加以综合引申
6. 照需求设计编码之,没有什么特殊之处,爱采用什么技术都行

zhrb 2008-03-18 12:47 发表评论

语源科技BlogJava-zhrb的空间

jEdit的一些常用设置

用UML做好系统分析(转载)

转载：奥卡姆剃刀

转载：奥卡姆剃刀

zz做JAVA开发要掌握的知识

用lucene建立简单的索引软件的一个需求

任务分发系统

填坑：oo的前世今生及后世(zz)

技术是一种加速器 但重要的不是技术(zz)

面向对象的思维方法 [zz]

需求分析很重要很强大

技术是一种加速器但重要的不是技术(zz)