- 浏览: 119673 次
- 性别:
- 来自: 成都
最新评论
-
ningningyudabao:
final class final {
fina ...
Final -
yongtree:
转载请注明出处,OK?
浅谈DAO工厂设计模式 -
rustlingwind:
好文好文,ding~~
关于领域建模的实现 -
daoyongyu:
谢谢楼主!!向楼主学习
jspSmartUpload上传下载全攻略 -
yinleiyoung:
以前用过一段时间,貌似有中文支持的问题,不知道现在是不是已经升 ...
jspSmartUpload上传下载全攻略
文章列表
AJAX框架:
Dojo
Dojo是一个非常强大面向对象,开源的JavaScript工具箱。它为开发Web胖客户端程序提供了一套完整的Widget和一些特效操作。
DWR
DWR(Direct Web Remoting)是一个WEB远程调用框架.利用这个框架可以让AJAX开发变得很简单.利用DWR可以在客户端利用JavaScript直接调用服务端的Java方法并返回值给JavaScript就好像直接本地客户端调用一样(DWR根据Java类来动态生成JavaScrip代码).它的最新版本DWR0.6添加许多特性如:支持Dom Trees的自动配置,支持Spring(JavaScript远程 ...
- 2008-06-29 14:02
- 浏览 982
- 评论(0)
Hibernate实体类==领域模型 ?
http://www.iteye.com/topic/11608
自从Martin Fowler的DDD提出来之后,无数的人就开始非议ORM方式下的持久化实体类,抨击这种方式下的实体类是“贫血”的,缺乏丰富业务语义的。其实他们都犯了一个最基本 ...
- 2008-06-29 14:00
- 浏览 1387
- 评论(0)
框架选择:
http://www.iteye.com/topic/205144?page=1
本文只是对论坛一个讨论帖子的整理,只供自己参考,别见笑!
struts+spring+ibatis+freemarker
国内某每日PV上亿的网站的架构,当然是集群来撑的。
集群不是万能,做不好,很影响性能 ...
- 2008-06-29 13:58
- 浏览 979
- 评论(0)
Final
final在Java中并不常用,然而它却为我们提供了诸如在C语言中定义常量的功能,不仅如此,final还可以让你控制你的成员、方法或者是一个类是否可被覆写或继承等功能,这些特点使final在Java中拥有了一个不可或缺的地位,也是学习Java时必须要知道和掌握的关键字之一。
final成员
当你在类中定义变量时,在其前面加上final关键字,那便是说,这个变量一旦被初始化便不可改变,这里不可改变的意思对基本类型来说是其值不可变,而对于对象变量来说其引用不可再变。其初始化可以在两个地方,一是其定义处,也就是说在final变量定义时直接给其赋值,二是在构造函数中。这两个地方只能选其 ...
- 2008-06-29 13:56
- 浏览 1243
- 评论(1)
关于不可变类和可变类
所谓不可变类,是指当创建了这个类的实例后,就不允许修改它的属性值。在JDK的基本类库中,所有基本类型的包装类,如Integer和Long类,都是不可变类,java.lang.String也是不可变类。以下代码创建了一个String对象和Integer对象,它们的值分别为“Hello”和 10,在程序代码中无法再改变这两个对象的值,因为Integer和String类没有提供修改其属性值的接口。
String s=new String("Hello");
Integer i=new Integer(10);
用户在创建自己的不可变类时,可以考 ...
- 2008-06-29 13:56
- 浏览 951
- 评论(0)
初始化顺序
1、调用顺序:
JAVA类首次装入时,会对静态成员变量或方法进行一次初始化,但方法不被调用是不会执行的,静态成员变量和静态初始化块级别相同,非静态成员变量和非静态初始化块级别相同。
先初始化父类的静 ...
- 2008-06-29 13:55
- 浏览 842
- 评论(0)
代码的坏味道
1、重复的代码
首当其冲的是重复代码。如果在一个以上地点看到相同的程序结构,那么可以肯定,设法将其合二为一,程序会变得更好。
2、长函数
拥有短函数的对象会活的比较好、比较长。间接层所带来的全部利益-解释能力、共享能力、选择能力-都是由小型函数支持的。
应该积极分解函数,应该遵循这样一个原则:每当感觉需要以注释来说明什么的时候,我们就把需要说明的东西写到一个独立的函数中,并以其用途(而非实现手法)命名。
我们可以对一组或甚至短短一行代码做这件事,哪怕替换后的函数调用比函数本身还长,只要函数名称能够解释其用途,我们也该毫不犹豫地那么做。
关键不在于函数的长度,而在于函数“ ...
- 2008-06-29 13:55
- 浏览 809
- 评论(0)
修改接口
1、接口修改了,什么事情都可能发生。
2、当需要修改的接口被那些“找不到,即使找到也无法修改”的代码使用时,接口的修改才会成为问题。这种情况下,我们会说,这个接口是“已发布接口”。
3、如果重构手法改变了“已发布接口”,你必须同时维护新旧两个接口,知道所有用户都有时间对这个变化做出反应,这不太困难。请尽量这么做:让旧接口调用新接口。当你修改函数名称时,请留下旧函数,让旧函数调用新函数。千万不要拷贝函数实现代码,那样会让你陷入“重复代码”的泥沼。
4、修改接口的典型例子:Java聚集类,Collection classes,Java2使用新聚集取代了原有的一些聚集接口。Java ...
- 2008-06-29 13:54
- 浏览 1020
- 评论(0)
重构笔记
1、好代码的两个重要标志:易读、易改。
2、重构的定义:在不改变代码的外在行为的前提下,对代码做出修改,以改进程序的内部结构。
3、当你发现自己需要为一个程序添加一个特性,而代码的结构使得你不能很方便的这么做,那么先重构那个程序,使得特性的添加比较容易进行,然后再添加特性。
4、设计不良的程序,往往需要更多的代码,因为在不同的地方存在使用完全相同的语句在做同样的事情。
5、重构可以改进设计,而改进设计的一个重要方向,就是消除重复代码。代码数量的减少不会使系统运行更快,然后代码数量的减少使得未来可能的修改变得容易的多。
6、重构可以使得代码更易读,而随着代码逐渐简洁,我们可 ...
- 2008-06-29 13:54
- 浏览 806
- 评论(0)
UP的阶段
1、UP项目将工作和迭代分为四个阶段:
初始,大体上的构想,业务案例、范围和模糊评估。
细化,已精化的构想、核心架构的迭代实现,高风险的解决、确定大多数需求和范围以及进行更为实际的评估。
构造,对遗留下来的风险较低和比较简单的元素进行迭代实现,准备部署。
移交,进行beta测试和部署。
2、初始阶段不是需求阶段,而是研究可行性的阶段,在此阶段要进行充分的调查以确定继续或种植项目。
3、细化阶段也不是需求或设计阶段,而是迭代地实现核心架构并解决高风险问题的阶段。
- 2008-06-29 13:51
- 浏览 957
- 评论(0)
UP的关键实践
1、UP倡导的核心思想是:短时间定量迭代、进化和可适应开发。
2、在早期迭代中解决高风险和高价值的问题。
3、不断让用户参与评估、反馈和需求。
4、在早期迭代中建立内聚的核心架构。
5、不断地验证质量:提早、经常和实际地测试。
6、在适当的地方使用用例。
7、进行一些可视化建模(使用UML)。
8、认证管理需求。
9、实行变更请求和配置管理。
- 2008-06-29 13:47
- 浏览 748
- 评论(0)
敏捷UP
1、推荐使用UP活动和制品的简集。记住,所有UP制品都是可选的,除非他们能够增加价值,否则避免创建这些制品。应该致力于早期的编程,而非构建文档。
2、UP是迭代的和不断进化的,所以在实现前的需求和设计都是不完整的。它们是在一系列迭代中,基于反馈而产生的。
3、以敏捷建模实践应用UML。
4、对于整个项目不应该有详细的计划。应该制定估计结束日期和主要里程碑的高阶计划(称为阶段计划),但是不要对这些里程碑详细定义细粒度的步骤。只能预先对一个迭代制定更为详细的计划(称为迭代计划)。详细计划是由一次次迭代的调整而完成的。
- 2008-06-29 13:47
- 浏览 1065
- 评论(0)
敏捷建模
1、建模(构建UML草图...)的目的主要是为了理解,而非文档。也就是说,建模的真正行为能够并且是应该能够对理解问题或解决方案空间提供更好的方式。从这个角度而言,实行“UML”(其真正含义是“实行OOA/D”)的目的并不是指设计者创建大量详细的UML图并递交给编程者(这其实是非敏捷的和面向瀑布的思维方式),而是指为良好的OO设计快速探索可选的方案和途径。
2、采用敏捷建模并不是不进行任何建模。
3、建模和模型的目的主要用于理解和沟通,而非构建文档。
4、不要对所有或大多数软件设计建模或应用UML。可以将简单的设计问题推延到编程阶段,在编程和测试中解决这些问题。只需要对设计空间 ...
- 2008-06-29 13:47
- 浏览 1032
- 评论(0)
如何进行迭代和进化式分析和设计
1、编程前的分析和设计并非毫无价值。迭代和进化式分析和设计是中庸之道。
2、精化的、高质量的需求基于反馈和计划的。在进行了项目过程的20%时,完成需求的精化,UP中,这一阶段称之 ...
- 2008-06-29 13:47
- 浏览 1059
- 评论(0)
瀑布生命周期
1、瀑布(或顺序)生命周期过程中,视图在编程之前详细定义所有或大部分需求。而且通常在编程之前创建出完整的设计或模型。同样试图在开始之前定义“可靠”的计划或时间表,但常常事与愿违。
2、瀑布模型与高失败率、低生产率、高缺陷率具有极大关系(与迭代项目相比)。
3、瀑布思维常常侵蚀迭代或UP项目。例如“让我们在开发编程之前编写所有用例”或“让我们在开始编程之前用UML完成更多详细的OO模型”。诸如这种不健康的瀑布思维错误地叠加在UP上的例子。
4、初始阶段进行大量的分析和建模是导致瀑布模型失败的一个关键原因。
5、错误假设:假设规格说明是可预知的和稳定的,并且能够在项目开始时 ...
- 2008-06-29 13:46
- 浏览 1178
- 评论(0)