设计模式是做一个好的架构的一个基础。那么设计模式具体的概念是啥呢？百度百科曰：设计模式（Design pattern）是一套被反复使用、多数人知晓的、经过分类编目的、代码设计经验的总结。使用设计模式是为了可重用代码、让代码更容易被他人理解、保证代码可靠性。
设计模式大致分三种类型，如下图：
要使我们的代码能被不同项目重用，让不同的人很便利地使用，那么设计模式就必须要用好。我们平时开发人机交互界面时，经常自觉或不自觉地使用到的设计模式有如下：
其中，对象创建部分控制程序的扩展性、对象的生命周期。
消息交互通常使用观察者模式来做消息机制，用消息驱动整个逻辑。
为了考虑程序的封装性，我们会使用很多方式来隐藏不需要公开的成员，限制调用，减少耦合性。
而一些复杂的特殊逻辑可以使用设计模式来巧妙地管理起来，如状态模式和命令模式。
当然，除此之外还会在HMI设计过程中用到其他的设计模式，这里仅仅是我目前想到的一些例子。
不管是什么设计模式，其实都要遵循以下6个原则：
（1）单一职责原则。通俗的说，即一个类只负责一项职责。为什么要这么做？一个类，多一个功能，就会多一个变更的因素。所以不要存在多一个导致类变更的原因，这样才能保证他更稳定，依赖它的类才更少地受影响。
（2）里氏替换原则。里氏替换原则通俗的来讲就是：子类可以扩展父类的功能，但不能改变父类原有的功能。它包含以下4层含义：
- 子类可以实现父类的抽象方法，但不能覆盖父类的非抽象方法。
- 子类中可以增加自己特有的方法。
- 当子类的方法重载父类的方法时，方法的前置条件（即方法的形参）要比父类方法的输入参数更宽松。
- 当子类的方法实现父类的抽象方法时，方法的后置条件（即方法的返回值）要比父类更严格。
（3）依赖倒转原则。定义：高层模块不应该依赖低层模块，二者都应该依赖其抽象；抽象不应该依赖细节；细节应该依赖抽象。总体来说，要针对接口编程。这一点很重要。我认为这是程序猿是否能处理和维护大工程的重要判断依据。如果你是针对接口编程的，当工程代码量变大之后，需求发生变化之后，你就不至于到处修改，而是可以通过扩展新的子类来实现，因为接口不变，所以使用它的类并没有受到影响，不需要做出修改。
（4）接口隔离原则。定义：客户端不应该依赖它不需要的接口；一个类对另一个类的依赖应该建立在最小的接口上。 原因还是减少依赖，不要存在多一个导致类变更的原因。
问题由来：类A通过接口I依赖类B，类C通过接口I依赖类D，如果接口I对于类A和类B来说不是最小接口，则类B和类D必须去实现他们不需要的方法。
解决方案：将臃肿的接口I拆分为独立的几个接口，类A和类C分别与他们需要的接口建立依赖关系。也就是采用接口隔离原则。
（5）迪米特法则。定义：一个对象应该对其他对象保持最少的了解。
问题由来：类与类之间的关系越密切，耦合度越大，当一个类发生改变时，对另一个类的影响也越大。
解决方案：尽量降低类与类之间的耦合。
（6）开闭原则。定义：一个软件实体如类、模块和函数应该对扩展开放，对修改关闭。
问题由来：在软件的生命周期内，因为变化、升级和维护等原因需要对软件原有代码进行修改时，可能会给旧代码中引入错误，也可能会使我们不得不对整个功能进行重构，并且需要原有代码经过重新测试。
解决方案：当软件需要变化时，尽量通过扩展软件实体的行为来实现变化，而不是通过修改已有的代码来实现变化。
如果在平时的设计中注意到了这几个原则，你的代码结果就不会差到哪里去。了解了常用的设计模式，你的结构就会更合理，更易于团队开发和维护。对于设计模式的入门，可以看看《大话设计模式》《headfirst：设计模式》这两本书，不过这两本书口水话比较多，仅适合入门，要深入研究的话，建议还是看看GOF的设计模式经典书籍《设计模式》。