序言
- 论软件设计模式及其应用
- 论可靠性与设计与应用
- 基于DSSA的软件架构和应用
- 论微服务架构及其应用
- 分布式系统设计
马上就要考试了，这个还是自己写完的第一篇论文。初步打算会写五篇。就是上面所写的。讲真的写这个东西还是一点思路都没有，这一篇的改动对非常大，暂时做个记录。也当是自己的勉励，加油。
论文
摘要：
2018年上半年,我在XX电子责任有限公司,作为气候组组长参与了陕西气象监测业务系统的开发。主要负责和客户的需求对接、关键模块的分析、系统的架构设计、开发人员的组织安排以及对开发和测试人员气候方面知识的培训。陕西横跨三个气候带，南北气候差异较大,气候事件种类繁多，共开发了暴雨、高温、沙尘、霜冻、华西秋雨、春季透雨、初夏汛雨等18类气候事件的监测评估模块。所以需求繁杂、变化性大、对业务系统要求高。基于项目的可扩展性和可维护性，我决定使用设计模式进行软件设计。
项目中主要使用工厂模式解决类的创建问题，利用策略模式解决不同气候事件统计算法之间的替换，利用模板方法模式提高代码的可复用性等。设计模式使我们简化软件设计、提高开发人员的沟通、降低技术风险和提高软件质量。为项目的成功奠定基础。
正文：
2018年上半年,我所在的公司开发了陕西气候监测业务系统。该项目共有12名成员。为了分工明确,主要分为前端组,后端组和测试组。其中美工组和GIS组在需要的时候配合工作。本人在项目中担任开发组长,主要进行和客户的需求分析和系统的架构、关键模块的设计、人员的组织和调配、对整体项目进度的把控。该项目建设的目的是应用于政府及大众的决策服务。帮助气象局建设气象信息现代化的平台，对各类气候事件的极端性、等级、历史排位等作出准确、及时的监测评估。
系统主要采用C/S和B/S的混合架构,其中C/S部分实现了各气候事件的基础数据查询
xx公司是一个很有实力的企业,公司90%的业务是关于气象的。而气象业务中气候又是公司最为重要的一块。目前气候业务已经覆盖了甘肃、宁夏和新疆三个省。再加上现在陕西的系统。四省的项目同时维护和开发，代价和成本都太高。所以迫切的需要我们能够基于各省的气象业务相同点和气候差一点。开发出一套统一的监测业务系统平台。通过对业务原型和以往经验分析,监测业务系统主要三大模块。一：气候事件的统计分析，陕西有18种，如高温、低温、霜冻、华西秋雨等。然后根据各省的特点不同高温模块又有高温日数、高温站数和站次、高温初终日、高温区域过程、？？二：产品模块的自动生成，因为每个科室都需要在月季年末的时候做大量的报表统计。为了解决解决重复他们的手动统计指标和效率低下提供模板的自动生成和在线编译。三：各种极端事件的大屏实时展示,主要的精确尺度为小时。
设计模式是一套被反复使用的、多数人知晓的、经过分类编目的代码设计经验的总结。常见的设计模式主要分为三大类，创建型模式、结构型模式、行为式模式。
创建型模式主要用于创建对象，为设计类的实例化提供指南。所包括的模式有Abstract Factory(抽象工厂)、Factory Method(抽象方法)、Singleton(单例模式)、Builder(建造者)、Prototype(原型)。
结构型模式主要用于处理类和对象的组合,对类如何设计以形成更大的结构提供指南。常见的模式有Composite(组合模式)、Facade(外观模式)、Proxy(代理模式)、Adapter(适配器模式)、Bridge(桥接模式)、Dectorator(装饰者模式)、Flyweight(享元)
行为型模式主要用于类或对象的交互以及职责的分配责任的方式提供指南。常见的模式有：Strategy(策略)、Memento(备忘录)、Visitor(访问者)、State(状态)、Chain of Responsibility(责任链)、Template Method(模板)、Observer(观察者)、Iterator(迭代器)、Commond(命令)、Interpreter(解释器)。
这里我主要介绍我们在数据处理和产品管理两个模块如何使用设计模式简化开发。
数据查询统计模块。需要统计日候旬月季年的历史数据。他们都要统计最高温、最低温、平均气温、降水距平百分率、降水量等。但是他们的统计算法有一定的差异。经过分析我们决定采用简单工厂模式来创建不同时间类型的对象。简单工厂模式是定义一个创建对象的接口,并让子类自己决定实例化哪一个类,将对象的实例化延迟到了子类。首先定义了一个TimePeriod(时间段)的总接口。然后分别由日候旬月季年去实现该接口。这样当添加一种新的时间段如上旬、春季等我们只要去修改工厂方法，而不用去修改业务逻辑代码。
上述模块中,不同对象中统计相同字段的算法统计相同。但是不同字段的统计方法各异。气温统计最大值和最小值,降水和日照统计累计值。都需要统计平均值。根据算法的差异,而尽可能的做到对象之间的解耦。我们决定采用策略模式。众所周知策略模式定义了一组算法集,让他们直接可以互换。我们首先定义了一个天气现象算法和时间段的汇总策略接口。在接口中定义了通用方法。接着在不同的子类中实现不同字段处理的算法。最后根据不同的输入条件和不同的时间段。实例化气候事件的实例类。然后汇总到汇总控制总类。汇总控制总类只和接口进行关联，不依赖于具体的子类。汇总控制种类负责执行具体的策略，并把数据放到相应的时间维度上。
一开始我们并没有采用策略模式。而是采取传统的方式。每种字段对应一个类来处理。随着项目的跟进，因为气候统计在中国仍然是一门在摸索的学科，后期客户的需求改动幅度很大。原本只要统计常见的气温、降水、日照。后面添加了霜冻、降雪等的统计。导致项目的臃肿和耦合度不断的提高。程序的可维护性越来越差而且工作量也越来越大。经过分析我们使用了策略模式，不但解决了后期添加的不同字段的统计方式，而且大大降低了后续的开发工作量。
在项目中我们还采用了模板方法模式,解决不同产品模板中多个子类共有的的方法且逻辑相同，提高代码的复用。使用中介模式解决多个业务逻辑类之间的项目耦合。设计模式使我们简化并加快设计、方便开发人员之间的沟通、同时降低开发降低风险。
设计模式简化并提高开发速度，提升软件质量，为项目成功奠定了坚实的基础。项目与2019年5月，被陕西气象局验收。各项功能指标都满足招标要求，得到客户的一直好评。但是由于项目时间和资源的限制，仍然有一些地方做的不足。因为我们我们的系统主要给科长和科员日常工作统计汇报所用，所以对数据的准确性和易操作性。为了快速帮助客户解决问题和提高代码的质量，所以对其他的质量属性。如性能达不到最佳水平。我们需要在设计模式和反设计模式之间找到平衡点，满足项目实际要求。同时加强技术专业水平，同时总结在项目中的教训和经验。为未来气候类软件贡献一份自己的水平。