回顾我的设计模式应用

经历了多个项目之后发现离开了所谓的设计模式，项目照样活得好好的。
回顾我参与的第一个项目，医院信息管理系统，在PowerBuilder6.5上开发，虽然我在这个系统上写了上万行代码，但是现在总结起来不外乎下面的工作

• 在窗体加载完成后从数据库中抓取数据
• 通过界面的各种事件，将数据库中的数据展现在窗口上
• 通过界面的各种事件，将界面的数据提交到数据库
• 通过界面的按钮事件，关闭当前窗口/打开别的窗口

十多年之后的今天，我用react native开发app项目，工作内容如下：

• 在app的界面加载完成后从后台api抓取数据
• 通过界面的点击/下拉/滑动等事件，对界面的数据进行处理
• 通过界面的点击事件，将数据提交到后台api
• 通过界面的点击事件，回退/打开别的界面

语言在变，框架在变，但工作的本质没有发生变化。

在这整个过程中，设计模式对项目的贡献到底有多大呢？

在参与项目的初期，我并不知道有设计模式的概念，对我来说程，要学习的内容如下：

1. 了解这个框架上提供了哪些钩子函数
2. 学习如何从数据库/后台api获取数据以及如何将数据更新到数据库/后台api
3. 学习如何将数据展现到界面上

加之可以很容易根据PowerBuilder里面有window的概念，将window直接映射为一个业务逻辑单元，因此一个庞大的医院信息管理系统就以数量庞大的window展现出来。

这种工作方式很直接，几乎不用动什么脑子，直接把业务需要映射到window的相关事件上，就可以像搭积木一样搭成一个庞大的系统。

随着工作的深入，发现重复的代码块越来越多，因此有必要抽象出一些公共类和公共方法，例如，用户，病人，科室，医生等，这里自觉不自觉的应用了过程抽象和数据抽象。

但是过程抽象和数据抽象也有不能解决问题的时候。

比如，门诊收费窗体完成一笔收费后，要通知其父窗体更新该病人的费用汇总数据。要解决这个问题只需要在打开门诊收费窗体时，传入一个回调函数；后来增加了一个简易显示器，要求将费用汇总金额更新到那个简易显示其上；再后来，接入了第三方系统，要求将数据更新到第三方系统上。

面对上面的业务增长，采用普通的过程抽象已经不能解决问题，因为每次涉及的对象都不一样。经过各种分析和学习，最后采用了行为型设计模式中的观察者模式来处理这类问题。

当我应用了观察者模式之后，发现实现设计模式的代码本身也给系统引入了一定的复杂型。

虽然，设计模式为了软件系统的扩展而生，但是其对业务变化的承受能力也是有限的，而且不恰当的使用设计模式会让软件系统变得更加难以维护。