前言
这是我在这写的第一篇博客，软件工程专业嗒，接触前端一年多了，目前正在实习。写博客主要是希望能督促记录自己的学习，也希望结交一群志同道合的朋友，大家一起讨论。
言归正传~，这一篇与下一篇UML算是预热篇，磨刀不误砍柴工嘛，设计原则是设计模式的基础，就像你要做应用题之前，总要会数手指和九九乘法表~。设计原则也是设计模式的指导，在各个设计模式中都会得到不同程度的体现，这些设计原则不仅体现在23个设计模式中，它也是指导我们写出优秀代码的明灯，哪怕不学习设计模式，设计原则也是要了解的，总不能一辈子做码农咯。
1.单一职责原则 SRP(Single Responsibility Principle)
一个超市，会有收银员，清洁工，摆放人员，运货员，仓库管理员等，这就是单一职责，即每个人只负责一件事。你能想象一个收银员还管运货或者摆放物品吗？
那你能想象一个类会负责很多功能吗？它只需要很好的完成自己负责的一个功能，少管其他类的闲事。一个系统就像一个大型公司，而你就是老总，你要善待你的员工，只有大家都在自己的岗位上各司其职，这样才能更好地协同工作，需要调换职员或者出问题需要找人的时候才方便。
大到超市，小到一个饭店，这是大家已经公认的高效工作方式，代码中的艺术来源于生活。
ps: 每个老总的观点都不一样，所以的什么职责算单一这个观点也会有所不同，所以这个原则最容易理解却也最容易违反~
2.开放-关闭原则 OPC(Open-Closed Principle)
简称开闭原则，即对扩展开放，对修改关闭。
现在超市的仓库管理员走了，你顶替了他的位置。这时经理来找你，说：哎呀，现在这气候改多进一些橘子和厚衣服啦。你只需要新增这两条业务即可，而不需要更新一遍你的整个系统。
感觉这个举栗子有点麻烦，总之，程序员都不喜欢修改以前的代码，这需要重新理解太多东西，而且有的时候并不希望这部分代码全部出现。你只需要把那些常用的会变化的部分预留出可扩展的方式，就可以省出很多的精力。
这个原则对编写可扩展的代码很6~。
3.里氏代换原则 LSP(Liskov Substitution Principle)
即子类型必须能够替换掉他们的父类。
你可能不理解，为什么我在使用子类的时候要使用父类？我不用不就得了。
这个可以倒着思考，一般来说一个子类会自动继承父类的非private得属性方法，这样的话在使用子类的地方当然可以使用父类啦，可是，，如果子类需要覆盖父类的方法呢？那就会与该原则相悖了。
继承也是扩展（Open）的一种方式，所以，该原则可以理解为父类要符合开闭原则，如果注定要被覆盖，可以使用抽象函数或者接口。
是不是很简单？时间不够啦，下周一再介绍另外三种。
