Java综合开发经验交流（公司机密）.pptVIP

开发经验交流（一） ——java程序设计的几个经验及其优缺点讨论 ——项目框架介绍 继承的使用 继承本身的出发点是为了使用父类（包括变量和方法） 继承HCache的子类 如果在设计一个类的时候，已经知道这个类是一个经常被继承的类，该类全部或者部分属性需要被子类使用。则定义为protected 优点：减少子类冗余代码。 缺点：继承者需要非常解父类。 常用场景：每个service都有共同的属性，如dao,paraPool等，而一个系统service非常多，为了避免每个service都重复去定义，生成，初始化这些基本元素，可采用继承机制。在这个场景中，优点远远要大于缺点。 有了这个父类，子类就简单很多了 抽象类的使用 应用场景：（1）完成一类事情，当事情还没发生的时候，我们可以确定事情发生时部分内容。 当这个部分所占的比重为0的时候，我们采用接口，因为这个时候我们只是知道事情发生的一个框架，一个定义。当这个比重为100的时候，我们采用实体类。因为这一类事情，我们一个类就能搞定。当这个比重在两者之间的时候，就是抽象类干的事情：它能做一部分，又有一部分不能做；能做的就定义成实体方法，不能做的就定义成抽象方法。 （2）当一个类被实例化并使用时，会出现程序异常或者业务异常。这种类也可以考虑定义成抽象类。（个人经验） 抽象类有一个形象的描述：模板 优点：只要能做的都可以做。 缺点：抽象类的设计难度太大，一类问题共性很容易被确定，但是个性却很难定义。很有可能解决了90%的问题，却解决不了最后10%的问题。 接口的使用 应用场景： 1）为一类问题定义统一的操作方式。 2）用类群解决问题时，扮演TODO功能。常用于搭建系统框架。在团队编程中有突出贡献。 3）一件事情有多种解决方案。 4）解决java不能多继承的缺点。 5）。。。。。。 1）为一类问题定义统一的操作方式 上图是一个用户操作的service接口。也就是说关于用户的操作都在这个类里可以调用到，以后关于用户所有操作，都从这个类里找。这样，为“关于用户操作”这一类问题就提供了完美的方案。 2）用类群解决问题时，扮演TODO功能。常用于搭建系统框架。在团队编程中有突出贡献。典型案例java.sql接口群。在这个包里，一共29个类，就有18个是接口。包括大家熟悉的Connection,ResultSet都是接口。可以用一句话概括这个包：它什么都干了，但是它什么都没干。 3)一类问题可以有多种解决方案。Java.sql.*同样是这个例子。关系数据库包括mysql,db2,oracle,sqlserver,access等等，各种数据库怎么实现由各自的厂商去做。这让我想起一句话：三流公司卖产品、二流公司做产品、一流公司卖标准。从这个角度，java.sql.*是一流的东西！ Context上下文 这个单词，非常常见。Xwork里的ActionContext，javax.servlet里的ServletContext, org.quartz里的SchedulerContext, org.springframework.context里的ApplicationContext 综上可知：上下文就是一个“临时数据库”，这个数据库的生命周期由定义者提供，如ActionContext的生命周期为一次Action的执行。在这个生命周期中，只要跟这个数据库有连接的都可以用到或者改变这个数据库的值。当然能否改变也由定义者确定权限。如ApplictionContext在一般情况下就是只读属性的。 以上是目前我们项目常用到的概念。下面介绍下项目框架 系统通常分四个文件夹：config放置配置文件；docs放置项目文档；src放置项目源代码；WebRoot放置项目页面 Config文件夹底下有几个关键的配置文件： Hibernate.cfg.xml 和perties：数据库连接配置文件 Hperties：系统参数配置文件 Service-mapping：接口与实现类的配置文件。 Qperties：调度器的配置文件。 Invoke/perties：各个接口方法反射调用的配置文件。 界面 父类Action service Action 界面 数据库 项目业务处理流程图 缓存Cache Session Action 数据库连接 项目介绍： 1）系统启动。在系统启动的时候，有多少常用数据需要加入到缓存中。 2）Action的寻址与页面跳转。 3）Action中，service的寻址 4）界面表单数据【包括单属性注入和模型注入】从界面到Action 5）Action中，相关参数的创建，包括数据库连接，用户Session等。 6）Action表单数据+相关参数，如何注入到s