??xml version="1.0" encoding="utf-8" standalone="yes"?>
]]>
]]>
]]>
]]>
andyyehoo:
比较一下下面的两段代码Q说真的Q虽然说Java效率低一点可以原谅,不过比较一下这两段代码的效率,真是..............虽然java效率?/span>C?/span>n个等U大安接受了,可是不意味着可以把pȝ效率丢到爪哇国去了啊
W一个是直接new一个对象,接着调用一个方法?/span>
W二个是首先getApplicationContextQ这个过E就首先不知道耗费多少了。然后是间接?/span>getBeanQ创Z个对象。接着通过调用3个比reflaction更低效率的方法,讄各个参数Q最后是调用?/span>
Ua的比较方法数Q已l是W一个的3倍了Q更不提每个Ҏ的效率比W一个还慢多?/span>
当然Q第二段的灵zL可能是高很多,但是q样的灵zL真的需要嘛Q在大部分系l的大部分区域,我们需要大量的?/span>EJB,JMS 或?/span> WEB SERVICE 里面切换嘛?
我们公司的答案不是,所以这个也是我们到现在q不普遍使用springQ而是部分使用spring的原因,也是spring的好处。系l小部分的灵zL需要非帔R的部分,我们才利?/span>spring?/span>beanfactory功能Q事务控制要求严格部分,才用它的事务管理功能。但是绝大部分,我们不用。可以说是刚柔ƈ吧Q不灉|的部分是刚,灉|部分是柔Q系l如果全部是柔的话,那就软ľl|力了Q如果全部是刚的话,那么太脆而易断,作ؓ一个真正实用的pȝQ刚柔还是按80/20原则的好?/span>
引用
UserManager userManager = new UserManager();
String userIDRetured = userManager.addUser("John Smith")
引用
ServiceRequest bsr = this.getApplicationContext().getBean("businessServiceRequest");
bsr.setServiceName("User Services");
bsr.setOperation("addUser");
bsr.addRequestInput("param1", "addUser");
String userIDRetured = (String) bsr.service();
gigix:
andyyehoo 写道:
比较一下下面的两段代码Q说真的Q虽然说Java效率低一点可以原谅,不过比较一下这两段代码的效率,真是..............虽然java效率比C低n个等U大安接受了,可是不意味着可以把pȝ效率丢到爪哇国去了啊
W一个是直接new一个对象,接着调用一个方法?
W二个是首先getApplicationContextQ这个过E就首先不知道耗费多少了。然后是间接的getBeanQ创Z个对象。接着通过调用3个比reflaction更低效率的方法,讄各个参数Q最后是调用?
Ua的比较方法数Q已l是W一个的3倍了Q更不提每个Ҏ的效率比W一个还慢多?
当然Q第二段的灵zL可能是高很多,但是q样的灵zL真的需要嘛Q在大部分系l的大部分区域,我们需要大量的在EJB,JMS 或?WEB SERVICE 里面切换嘛?
你讲q么大一通,我说你纯_Ҏ淡。只?/span>addUserҎ里面讉K一ơ数据库Q你所有那些性能考量全都是白贏V哪怕你节约一万次对象创徏和方法调用,q接数据库的|络开销p以让你的整个努力化ؓ乌有。你也知?/span>80/20原则Q按?/span>80/20原则Q?/span>J2EE应用Ҏ׃应该考虑性能问题Q除非涉及到RPC?/span>I/O操作。你在内存里优化得再好,如果׃架构上的原因多一?/span>RPC调用Q整个系l的性能立马掉下来了。与其追求这U毫无h值的、微U的性能提升Q我宁可q求全面的灵zL?/span>
andyyehoo:
gigix 写道:
你讲q么大一通,我说你纯_Ҏ淡。只?/span>addUserҎ里面讉K一ơ数据库Q你所有那些性能考量全都是白贏V哪怕你节约一万次对象创徏和方法调用,q接数据库的|络开销p以让你的整个努力化ؓ乌有。你也知?/span>80/20原则Q按?/span>80/20原则Q?/span>J2EE应用Ҏ׃应该考虑性能问题Q除非涉及到RPC?/span>I/O操作。你在内存里优化得再好,如果׃架构上的原因多一?/span>RPC调用Q整个系l的性能立马掉下来了。与其追求这U毫无h值的、微U的性能提升Q我宁可q求全面的灵zL?/span>
addUser调用数据库的旉Q大安是一LQؓ什么我不能考虑q里调优Q?/span>
q样写,q不会多Zơ数据库或?/span>RPC的调用。除非是很复杂的部分Q那么我会考虑局部用。对于系l?/span>80Q的代码Q简单化处理是不会带来Q何问题的?/span>
J2EE应用Ҏ׃应该考虑性能问题Q那我所有字W串q接都用+好不好?我做一?/span>catch一?/span>exception好不好?我所?/span>JavaҎ的调用都通过reflectionq行好不好?“Ҏ”q个词用得太q了?/span>
"我宁可追求全面的灉|?/span>",q个正是问题所在,q分的追求灵zL,降低效率,我们必须在灵zL和效率中间取得q炏V?/span>xxx说了“d多一个中间层Q可以解军_部分的问?/span>”。中间层多Q当然灵zL约好,但是效率是低了。其实当Ӟ效率q个东西是两头大Q中间小的一个东西,最耗费旉的,往往是一开始的调用Q用LM到处理层Q和最后的调用Q调用数据库Q?/span>WEB serviceQ,但是qƈ不意味着Q我们就可以无节制的Q忽略中间的效率?/span>
gigix:
andyyehoo 写道
addUser调用数据库的旉Q大安是一LQؓ什么我不能考虑q里调优Q?
q样写,q不会多Zơ数据库或者RPC的调用。除非是很复杂的部分Q那么我会考虑局部用。对于系l?0Q的代码Q简单化处理是不会带来Q何问题的?
你是真不明白呢还是故意抬杠?一ơ数据库操作或?/span>RPC的速度是十毫秒U的Q通常一?/span>J2EE业务操作包括几次|络传输和几ơ数据库操作Q也是说在最理想的情况下一个业务操作的速度是百毫秒U甚至秒U的。我请问你,你要节省多少ơ对象创建、多次Ҏ调用才能把响应时间提?/span>100毫秒Q有个成语可以脓切地形容q种优化Q杯水R薪?/span>
andyyehoo 写道
J2EE应用Ҏ׃应该考虑性能问题Q那我所有字W串q接都用+好不好?我做一步catch一ơexception好不好?我所有JavaҎ的调用都通过reflectionq行好不好?“Ҏ”q个词用得太q了?
你还真说对了。我所有字W串q接都是?/span>+Q我的业务对象外面有动态代理提供的AOPQ也是说所有方法调用都是通过reflectionq行的;我的动态代理里面对异常全部做了包装Q也是说每个方法调用都?/span>try...catch...的包裏V我得到的效果是什么?更清晰的代码Q更优雅的架构,以及Q更Ҏ扑ֈpȝ的性能瓉Q更Ҏ优化性能。有些事情也怽没有听说q,但不代表它不是真的?/span>
andyyehoo 写道
"我宁可追求全面的灉|?,q个正是问题所在,q分的追求灵zL,降低效率,我们必须在灵zL和效率中间取得q炏Vxxx说了“d多一个中间层Q可以解军_部分的问?#8221;。中间层多Q当然灵zL约好,但是效率是低了。其实当Ӟ效率q个东西是两头大Q中间小的一个东西,最耗费旉的,往往是一开始的调用Q用LM到处理层Q和最后的调用Q调用数据库QWEB serviceQ,但是qƈ不意味着Q我们就可以无节制的Q忽略中间的效率?/span>
同样一个问题,我换另一个角度来问你Q你要做多少ơ字W串q接Q才能浪?/span>100毫秒旉Q你可以自己写个E序Q对比一?/span>StringBuffer.append?/span>String.+的性能差距Q看看需要多大的字符串才能让你损?/span>100毫秒。如果你能告诉我q个l果Q我一定很有兴知道。别忘了Q?/span>100毫秒仅仅是一ơ普?/span>J2EE业务操作整体响应旉的数十分之一而已?/span>
andyyehoo:
引用Q?/span>
你还真说对了。我所有字W串q接都是?Q我的业务对象外面有动态代理提供的AOPQ也是说所有方法调用都是通过reflectionq行的;我的动态代理里面对异常全部做了包装Q也是说每个方法调用都有try...catch...的包裏V我得到的效果是什么?更清晰的代码Q更优雅的架构,以及Q更Ҏ扑ֈpȝ的性能瓉Q更Ҏ优化性能。有些事情也怽没有听说q,但不代表它不是真的?
lol: 我相信你的系l是q样的,但是不代表所有的pȝ都需要象你这栗对于很多中型pȝ来说Q如此优雅的架构q不都是必须的?
而且Q你q样对开发的效率有媄响,代码量又多啦Q呵呵,对开发h员M素质的要求也高了不少Q公司的成本又高囖?q些都是需要考虑的?evil:
当然Q我承认后一U方法的先进性和灉|性,但是Q还是那个问题,不需要拿牛的杀鸡,而现在的市场Q鸡q是比牛多一些?/span>
gigixQ?/span>q也是你的想当然。如果采用一个优雅的架构Q普通程序员只需要编写面向对象的E序p够了。他不需要考虑如何理事务Q他不需要考虑如何记录日志Q他甚至不需要考虑如何获得和关闭数据库q接Q而且他写的每个模块都可以从系l中摘出来单独测试。难道开发这LE序会更慢、写更多的代码、对开发h员要求更高?相反Q如果做太多代码U的优化Q势必损x构的优雅和灵z,会导致更多的重复代码Q会使得各个模块耦合紧密而不能独立测试,那样的系l才是代码量更多、对开发者要求更高的?/span>
我只举一个最单的例子。你认ؓ如果我们需要一?/span>UserManagerQ那么就直接new UserManager()好了。但是这样一来,开?/span>client代码的h无法只试他自q业务逻辑Q他的单元测试还必须同时兼顾UserManager的逻辑。我请问你,q是不是比写一?/span>mock来测试自p一个模块有更高的难度?一?/span>UserManager修改了实玎ͼ它的作者必M所有用者沟通,以保证这些h的单元测试不会失败,q是不是增加了工作量降低了开发效率?如果client代码能够q样写:
[code:1]
public class MyClass {
private UserManager _um;
public void setUserManager(UserManager um) {
_um = um;
}
public void doSomething() {
_um.doSomething();
}
}
[/code:1]
~写client的h不必考虑该创?/span>UserManager的哪个实现类Q也不必考虑如何创徏Q也不必兛_q个对象的生命周期,也不用管它是本地对象q是RPC stub。难道这样写E序不是更轻松、代码量更少、对E序员的要求更低吗?
andyyehooQ?/span>
gigix写道Q?/span>
q也是你的想当然。如果采用一个优雅的架构Q普通程序员只需要编写面向对象的E序p够了。他不需要考虑如何理事务Q他不需要考虑如何记录日志Q他甚至不需要考虑如何获得和关闭数据库q接Q而且他写的每个模块都可以从系l中摘出来单独测试。难道开发这LE序会更慢、写更多的代码、对开发h员要求更高?相反Q如果做太多代码U的优化Q势必损x构的优雅和灵z,会导致更多的重复代码Q会使得各个模块耦合紧密而不能独立测试,那样的系l才是代码量更多、对开发者要求更高的?/span>
在正规公叔R面,分工明确的话Q都是专人写好架构,普通程序员按照架构往里面填代码就是的啦。正常情况下Q他也是不需要如何管理事务,记录日志Q获得和关闭q接Q每个模块也可以单独试?
但是Q程序调试出错的时候,他们也需要自己查看日志,考虑一下各方各面的因素才能调试Q按照第二种写法Q无疑,q些E序员的素质要相寚w一些,考虑的问题更多一些,才能q行调试的?
gigix写道Q?/span>
我只举一个最单的例子。你认ؓ如果我们需要一?/span>UserManagerQ那么就直接new UserManager()好了?/span>
q个是例子这么写的,需要灵zȝ部分Q我们自然会用其它方法写。不q在最单的情况中,我们是会q么写,更简单的情况Q直接还调用静态方法,不会不给吧,呵呵
gigixQ?/span>
andyyehoo 写道
q个是例子这么写的,需要灵zȝ部分Q我们自然会用其它方法写。不q在最单的情况中,我们是会q么写,更简单的情况Q直接还调用静态方法,不会不给吧,呵呵 :lol:
别的不多_pq一件事好了。我要求所有程序员严格遵@“针对接口~程”的原则,每个lg必须提供一个接口和一个实玎ͼ获得lg必须以接口的形式、通过dependency injection获得。而按照你的说法,你要求程序员在提供功能时有时针对接口~程Q有旉对对象编E,有时静态方法实玎ͼ也就是说你要求程序员清楚q三U设计的语义区别和利弊权衡。我惌问你Q究竟是谁对E序员的要求更高呢?
andyyehooQ?/span>
引用
别的不多_pq一件事好了。我要求所有程序员严格遵@“针对接口~程”的原则,每个lg必须提供一个接口和一个实玎ͼ获得lg必须以接口的形式、通过dependency injection获得?/span>
佩服佩服Q没有程序员抗议嘛?
引用
有时针对接口~程Q有旉对对象编E,有时静态方法实玎ͼ也就是说你要求程序员清楚q三U设计的语义区别和利弊权衡?/span>
我们现在是这P不过Q这个好像是JAVAE序员的基本功吧Q虽然现在很多程序员基本功不好,那样的话Q还是我们要求高点,按照你那样写的话Q都快可以机器生代码了Q呵呵,可以考虑开始向自动产生代码发展了?
不过嘛,q是那个问题Q出了bugQ你们调试还是比较困隄吧?
gigixQ?/span>
andyyehoo 写道
引用
别的不多_pq一件事好了。我要求所有程序员严格遵@“针对接口~程”的原则,每个lg必须提供一个接口和一个实玎ͼ获得lg必须以接口的形式、通过dependency injection获得?/span> |
佩服佩服Q没有程序员抗议嘛?
引用
有时针对接口~程Q有旉对对象编E,有时静态方法实玎ͼ也就是说你要求程序员清楚q三U设计的语义区别和利弊权衡?/span> |
我们现在是这P不过Q这个好像是JAVAE序员的基本功吧Q虽然现在很多程序员基本功不好,那样的话Q还是我们要求高点,按照你那样写的话Q都快可以机器生代码了Q呵呵,可以考虑开始向自动产生代码发展了?/span>
不过嘛,q是那个问题Q?/span>ZbugQ你们调试还是比较困隄吧?
对象怎么创徏、对象的生命周期怎么理Q这些都是跟业务没关pȝinfrastructure。让E序员可以不操心q些infrastructureQ一心关注自q业务逻辑Q怎么会有人抗议?
你说“调试比较困难”Q我q的很怀疑你I竟有多经验了。Q何一个有l验?/span>J2EE开发者都会知道,OOD做得好Q?/span>debug轻松?/span>OOD做得好,你才可能做出完备的单元测试,然后用单元测试快速锁?/span>debug的范围。我们调试比较困隑Q我真的不知道该怎么回答q个问题Q因为我已经好久没开q?/span>debugger了?/span>
andyyehooQ?/span>
引用
你说“调试比较困难”Q我q的很怀疑你I竟有多经验了。Q何一个有l验?/span>J2EE开发者都会知道,OOD做得好Q?/span>debug轻松?/span>OOD做得好,你才可能做出完备的单元测试,然后用单元测试快速锁?/span>debug的范围。我们调试比较困隑Q我真的不知道该怎么回答q个问题Q因为我已经好久没开q?/span>debugger了?/span>
所指的bugQ是指需要在spring的配|,aop搭徏的事务控Ӟ日志中穿梭寻扄bugQ不q这个对于你来说应该是很熟了Q所以没什么感觉了Q一样快速锁定了。应该就是良好的架构使这定位个过E很快的。反正有固定步法的话Q走7步和?步差不多吧,呵呵?/span>
gigixQ?/span>
andyyehoo 写道
引用
你说“调试比较困难”Q我q的很怀疑你I竟有多经验了。Q何一个有l验的J2EE开发者都会知道,OOD做得好Qdebug轻松。OOD做得好,你才可能做出完备的单元测试,然后用单元测试快速锁定debug的范围。我们调试比较困隑Q我真的不知道该怎么回答q个问题Q因为我已经好久没开qdebugger了?/span> |
所指的bugQ是指需要在spring的配|,aop搭徏的事务控Ӟ日志中穿梭寻扄bugQ不q这个对于你来说应该是很熟了Q所以没什么感觉了Q一样快速锁定了。应该就是良好的架构使这定位个过E很快的。反正有固定步法的话Q走7步和?步差不多吧,呵呵?/span>
q些事情更不需要debugQ因为它们都在冒烟测试的范围内。只要一开始测试通过Q你做了一件事以后变得不通过了,马上可以知道是你刚才的改动造成了破坏。这里没?步?步的调试Q只?步:回退你上一分钟做的修改?
说v来,好象你也开始赞成:OOD和良好的架构才是真正重要的,而不?0毫秒的性能提升?/span>
andyyehoo:
引用
说v来,好象你也开始赞成:OOD和良好的架构才是真正重要的,而不?/span>20毫秒的性能提升?/span>
:lol: 我一直的观点是,OOD和良好的架构当然很重要的Q但是要Ҏ目选择合适灵zȝ架构Q而不必全部采用最灉|的系l,而在q个基础上,“20毫秒的性能提升”Q也是需要考虑的事情之一Q而不可以完全抛之脑后?
H然惛_A计划2成龙说的Q我不能接受M人,以国家民族利益的崇高名义Q草菅Q何无辜市民的生命。(C太清Q大概)哈哈Q有点象
UP的几个核心概念,也可以说是最佛_践:用例驱动Q所有的分析设计试都是围绕用例展开Q,q代Q因此我们会不断地编写用例,l制用例图,q行分析Q设计,实现Q部|和试zdQ,ZlgQ我们看到最后Y件是q件构成的Q,以架构ؓ中心Q分层架构,完整的对象模型,核心领域模型Q?/span>
核心工作?/span> |
模型 |
q程 |
UML?/span> |
需?/span> |
用例模型 |
1 描述企业的业务流E,~写业务用例Q然后以用例图来表示各个用例之间的关p(include/extendQ,及用(useQ该用例的参与者(ActorQ?/span> |
用例?/span> |
2 使用zd图来表示业务程 |
zd?/span> |
||
3 Ҏ业务程Q明系l功能,~写pȝ用例Q用用例图表示各个用例之间的关p,及用该用例的参与者?/span> |
用例?/span> |
||
4 使用pȝ序图描q系l事件与pȝ操作 |
序?/span> |
||
分析 |
分析模型 描述用例实现的对象模型,它是工gQ设计模?/u>的一个抽象?/span> 分析模型包含用例分析的结果?u>工gQ分析类的实例?/span> 用例实现-分析 |
5 对于用例中的一个或多个场景q行分析Q然后抽象出一些分析类Q包括边界类Q控制类和实体类Q,分析cd被映ؓ设计c(分析cM表角Ԍ一个分析类可以?/span>1或多个设计类实现Q。分析类也可以称之ؓ业务模型Q或者是领域模型。分析类通常可跨多个用例,其表C领域中的概c?/span> |
cd |
6 分析cM分析cM间的交互Q由协作图来表示。这L之ؓ用例实现?/span> |
协作?/span> |
||
以上两者再辅之以文本,可以用来描述用例实现Q每个用例对应于一个用例实?/span>[1]?/span> |
|
||
设计 |
设计模型 用例实现-设计 |
7 设计cM表系l中完成功能的类。它受到分析cȝ启发或者是Z解决一些Y仉题而被设计出来?/span> |
cd |
8 用例实现。根据分析模型中的用例实玎ͼ来完成设计模型中的用例实现?/span> |
序?/span> |
||
可以使用包图来表C系l的分层架构?/span> |
|
||
10 某些设计对象是由状态决定的Q也是说根据其状态的不同Q其会表现出不同的行为。状态图可以表示一个对象的状态{换关pd序Q可以理解ؓ对象状态流E图?/span> |
状态图 |
||
实现 |
实现模型 |
11 系l抽象ؓlgQ实现模型即q件构成。这W合UP包含Zlg的思想。(Jacobson是组件开发之Ӟ |
lg?/span> |
实施 |
实施模型 |
12 实施模型Ҏ怺q接的节点定义实际的pȝ架构?/span> |
实施?/span> |
[1] [Larman03]?/span>Rose?/span>RUP模板中都认ؓ用例实现属于设计模型Q然而本书认为分析模型和设计模型中都存在用例实现Q在分析模型中,用例实现表现为领域对象与领域对象之间的交互,设计模型中,表现计类与设计类之间的交互。不q由?/span>UP是用例驱动开发的Q因此,Z用例的分析与设计Q都可以理解为用例实现?/span>