混合模式在汽车保险服务中的应用

前言：想要写出一篇引人入胜的文章？我们特意为您整理了混合模式在汽车保险服务中的应用范文，希望能给你带来灵感和参考，敬请阅读。

1车险业务及解决方案

汽车保险服务系统是专门为汽车保险计算业务而设计的系统，该系统采用SSH框架进行整体实现，由于页面展示内容多为表格统计操作，因此在系统的前端设计中引入了JQuery11.1及Ext.JS，系统数据库采用MySQL进行设计实现。影响核心业务车辆保险计算模块的主要因素包括车辆购置价格、保险费率、基础保费、折扣系数、车辆类型折扣等因素，而这些因素的取值大部分都取决于公司所在地保险业标准、车辆类型及车辆使用年限三个因子。而这三个因子或者会因地域变化而变，或在在业务扩张过程中对车辆类型进行调整，变动性较大，因此相关模块需要采用有针对性的措施尽可能的为系统提供高可复用性、可扩展性的设计方案。具体的解决方案如下：1）由于公司业务可能会涉及多个地区，因此为了适应各地不同的费率标准，在系统设计中将各类标准费率录入系统的数据库中，而在系统的具体实现中使用变量代替这些因子的具体值，这样既可避免业务扩张所带来的大量代码修改，同时也提高了代码的可复用率。（2）客户车辆保险应缴纳费用取决于客户选择投保的险种及类型，即在计算过程中动态的增减一些类目，为了使系统具有更好的可扩展性，该部分的设计采用装饰者模式进行设计、实现。（3）车辆保险的包含自燃险、玻璃单独破碎险、全车盗抢险、车上人员险（包括司机和乘客两类）、第三者责任险、机动车损失险（以下简称车损）等，所有险种依据参数的不同又可以进行细分，运用抽象工厂模式可以降低最终的保险计算与具体险种计算的耦合度、增强保险运算的灵活性。

2设计模式的应用

2.1装饰者模式的应用

自此类，作为计算主体的TotalFee类中将返回交强险与车船税之和，而其他的险种被视为TotalFee的“装饰者”，对超类Insurance进行扩展，针对各类保险的具体计算方法calculateInsurance的重写通过抽象工厂模式来进行完成。因此，在每种险种的类中都包含了对具体的工厂类的引用。保险服务系统中的装饰者模式应用类图如图1所示。

2.2抽象工厂模式的应用

在2.1节中提到具体的每种保险的计算是通过抽象工厂模式来设计实现的，详情如图2所示。该保险服务系统中的保险分为两类：基本险和不计免赔两类，而基本险根据不同的车辆类型同一种险种的计算公式也不同，具体表现为所有私家车的基本险的金额都要在其他类车辆保险金额的基础上乘以一个车辆类型系数，如0.9（该系数可能会因地区而异），因此系统实现中将用两个具体的工厂类来针对私家车及非私家车的保险进行计算。VehicleInsurance类为所有种类保险的一个代表，具体类为图1中的装饰者类，在这个类中对具体情况的保险进行计算，而这种计算依赖于VehicleInsuranceFactory接口的具体实现，即私家车保险计算工厂类PrivateVehicleInsFactory或者非私家车保险计算工厂类OtherVehicleInsFactory，而每个工厂类都依赖着各个保险接口的具体实现类。系统中所有的保险都有各自的接口，每个接口又根据私家车与非私家车的类型分为两种具体的实现分别于两个具体的工厂类相对应。

3结束语

使用装饰者模式进行客户需缴纳费用计算的设计方式取代简单的继承处理，使得系统的运算更加灵活，在后期维护工作中可改动少量代码即可达到保险种类变更的简单处理。同时抽象工厂模式的使用使得所有种类的保险计算都可以通过接口调用来完成，对象调用时无需关注具体方法实现过程，降低了具体方法的实现对保险计算过程的影响。通过这两种模式的混合设计，基本将系统中保险计算的易变因素都进行了封装处理，并大多采用组合而非继承的方式使多数类之间的耦合度大大降低，增强了系统的可扩展性及可复用性。尽管这种混合模式的设计有利于系统的修改及维护，但由于类的增加，从而加重了系统跟踪、文档撰写的工作量，因此对于所有类的使用说明、修改等工作都应尽可能详尽的阐述。客户缴纳金额取决于投保种类、车辆特性等参数，其中机动车交通事故强制责任险（以下简称交强险）、车船税等金额是固定需要缴纳的费用，而其他的投保险种因客户而异，因此可以将交强险与车船税二者之和作为最终缴纳金额的主体，然后再运行时再根据客户的不同需求动态的添加其他险种金额。具体的作法是将共有的部分保险类别insType属性及计算客户应交费用的方法calculateInsurance。

作者：陈海燕 何明祥 单位：山东科技大学