架构复用

架构复用

好久没有写博客了今天开博,对我所做的项目做一个总结如下:

1. 原则：区分变化，不变化内容。

2. 一、"开－闭"原则，模块应对扩展开放，而对修改关闭。模块应尽量在不修改原(是"原"，指原来的代码)代码的情况下进行扩展。
此软件采用“插件”技术，功能可以无限扩展。你自己就可以添加功能（不需要您写代码）。

3. 二、里氏代换原则，如果调用的是父类的话，那么换成子类也完全可以运行。
目前大多数软件都是为了添加一个功能，或修改一个很小的地方都要返回到软件提供商技术部修改代码，重新编译，打包发行。
也许您不能理解，举一个生活中的例子，换被罩，现在您用的是一个花被罩，脏了或颜色您不喜欢，想换成一个红色的新被罩。您的做法
把被子拿下来，被罩一拆，直接一换就OK了。不需要把被子拆了，床也拆了。类比软件，现在我的需求是：我想换一下界面风格，颜色，软件中某个功能。
常规软件都要把需求反馈给软件开发商，领导签字确定更改软件，文秘提交给开发经理，经理再把任务交个程序员修改代码，编译，测试，打包。整个一个复杂的流程，
用户很不理解，就像刚才我举的一个”换被罩“的例子。为了一个软件小小的变化，都要把软件重新走一个复杂的流程。无过于为了换一个被罩把被子也拆了，床也拆
了重新组装。如果软件是这样，说明软件设计上存在缺陷。

4. 三、合成复用原则，就是说要少用继承，多用合成关系来实现。这样写过程序：有几个类要与数据库打交道，就写了一个数据库操作的类，然后别的跟数据库打交道的类都继承这个。结果后来，修改了数据库操作类的一个方法，各个类都需要改动。"牵一发而动全身"!把波动限制在尽量小的范围。
将已经有的功能重新组合形成一个符合您要求的功能。就像金庸武侠小说里面，锻玉学的化功大法一样，能吸收各个门派的功力为我所用。

5. 数据库访问：增，删，改，查,调用带参数存储过程，调用不带参数存储过程，返回数据集。
对数据库的操作，充分发挥数据库内部提供的功能。

6. 软件架构分层次：数据库，访问数据库构件，审计业务构件，用户交互界面表现。
程序层次分明，职责分明，统一管理，条理思路清晰，保证软件质量，减少bug.
7. 各种控件合利用。
一处编写处处使用。一个功能只实现一次，其他地方可以利用这个已经有的功能，或执行此功能的结果。
8. 打破规则。创造新规则。
技术上创新，将新的知识理论应用到实践中去。

9. 用理论指导编程，从实践中总结理论。
根据自己的想法，结合理论，去探索开发软件。开发完成后总结优缺点。