今天谈谈开发中比较重要的知识点：代码设计
直接进入正题：
模块化：网上资料有很多关于MVC、MVP...但是对于刚入行的朋友却有些不友好。如果单纯的将项目使用MVP，对于小demo还好，对于庞大的项目，却是有些不够用了。合理设计代码框架：项目应以模块划分，小模块如果功能够丰富，就继续划分，最后再用上MVC、MVP。
模块化的核心是为了解决耦合问题，耦合问题的前提是抽象，抽象出合理的逻辑再进行开发。通常在没有将业务逻辑理解透彻的情况下进行的设计，却是会出现很多纰漏。合理的抽象需要尽可能考虑全面，经验和思维能力可以帮上不少忙。
设计模式：在此不过多阐述，有兴趣的可以查看别人写的文章：
http://www.cnblogs.com/maowang1991/archive/2013/04/15/3023236.html
设计原则：是开发的重点，需要常用也需要合理运用：
总结下可以从三个层面来理解：代码层面、模块层面及类层面
（代码层面）开闭原则：对扩展开发，对修改闭合。
尽量编写可复用的代码，减少代码冗余。
（模块层面）依赖倒置原则：
A.高层次的模块不应该依赖于低层次的模块，他们都应该依赖于抽象。
B.抽象不应该依赖于具体实现，具体实现应该依赖于抽象。
进一步理解：高层次的模块可以理解成框架，即框架不应该依赖于具体业务，而是依赖于业务的抽象。抽象即对事物的总结，在平常开发中将产品的设计图总结出可实用的框架即是抽象的结果。
（类角度）类单一职责原则：
A.一个类只有一个引起这个类变化的原因。
B.一个类中应该是一组相关性很高的函数和数据的封装。
类单一原则应该比较好理解，可以扩展下：即一个类只完成一个功能，如果做不到一个类只完成一个功能，最少要保证一个方法只完成一个功能。反例（忘了哪里摘来的）：T负责两个不同的职责：职责P1，职责P2。当由于职责P1需求发生改变而需要修改类T时，有可能会导致原本运行正常的职责P2功能发生故障。
（类角度）迪米特法则：
也叫“最少知道原则”，一个类尽量少的与其他类发生关系，每一个类对其他类都只有最少的联系，而且局限于与本类密切相关的类。
与“类单一原则”互补，“类单一原则”主内，“迪米特法则”主外，都是在阐述在类定义时应该注意的。
（类角度，抽象类）里氏替换原则：
任何
基类可以出现的地方，子类一定可以出现。只有当衍生类可以替换掉基类，软件单位的功能不受到影响时，基类才能真正被复用，而衍生类也能够在基类的基础上增加新的行为。里氏代换原则是对“开-闭”原则的补充。实现“开-闭”原则的关键步骤就是抽象化。而基类与子类的继承关系就是抽象化的具体实现，所以里氏代换原则是对实现抽象化的具体步骤的规范。
（类角度，接口）接口隔离原则：
一个接口完成的功能尽可能的单一，不要让一个接口承担过多的责任。
这个原则主要是为了防止为了偷懒，直接使用一个接口，实现多个接口应该实现的方法。