当我们在进行软件设计时，首先我们要充分地调查、收集用户的需求，今天老师说的一句话让我很受启发：变是永远不变，相对于我们的程序设计而言，用户的需求是时刻在变得，那我们怎样做才能满足客户的各种需求呢，众所周知，当我们的程序满足设计模式的六大原则时，程序会更加灵活，下面是小编对六大原则的理解：
单一职责原则：Single Responsibility Principle
定义：一个类只负责一项职责
就一个类而言，仅有一个引起它变化的原因，小编遇到的最大的问题是对职责的定义，什么是类的职责，以及怎么划分类的职责，这需要靠个人经验界定。
目的：降低类的复杂性，可读性提高，可维护性提高。
里式代换原则：Liskov Substitution Principle
定义：子类继承父类，单独完全可以运行
任何基类出现的地方，子类一定可以出现。LSP是继承复用的基石，只有当衍生类可以替换掉基类，软件单位的功能不受影响时，基类才能真正被复用，而衍生类也能够在基类的基础上增加行的行为。
举例：球类，原本是一种体育用品，他的衍生类有足球、篮球等等，如果衍生类替换了基类的原本方法，如把体育用品改为了食用品（那么软件单位的功能受到影响），就不符合历史代换原则。
目的：对实现抽象化的具体步骤的规范。
依赖倒转原则：Dependence Inversion Principle
定义：高层模块不应该依赖底层模块，两个都应该依赖于抽象。抽象不应该依赖于细节，细节应该依赖于抽象
该原则针对接口编程，而不是针对实现编程，引用一个对象，如果这个对象有底层类型，直接引用底层类型。
举例：以计算机系统为例，无论主板、CPU、内存、硬件都是针对接口设计的，如果针对实现设计，内存就要对应到针对某个品牌的主板，那么如果需要换内存必须得吧主板也换掉，不符合设计原则。
目的：降低模块间的耦合度。
接口隔离原则：InterfaceSegregation Principles
定义：一个类对另一个类的依赖应建立在最小的接口上
为每个类建立专用的接口，而不要试图去建立一个很庞大的接口供所有依赖它的类调用，客户端也不应该依赖它不需要的接口，每一个接口应该是一种角色。
举例：登陆和注册属于用户模块的两个接口，比写成一个接口好。
目的：提高程序设计的灵活性。
注：接口尽量小，但是要有限度。接口太小会造成接口数量过多，是设计复杂化，所以接口要适度。
迪米特原则：Law of Demeter
定义：一个实体应当尽量少的与其他实体之间发生相互作用
迪米特原则也叫”最少知道原则“，一个对象应对其他对象有尽可能少的了解（只与你的直接朋友交谈，不跟“陌生人”说话）。
举例：一个公开的public属性或方法越多，修改时涉及的面也就越大，变更引起的风险也就越大。
目的：降低类之间的耦合，减少对其他类的依赖。
开闭原则：Open Close Principle
定义：对拓展开放，对修改关闭