版本1：计算5与6的和
主题讨论：《从《版本1：计算5和6的和》中，这样极其简单的代码，你写的多吗？从中你又能发现什么？》
感受：直接放了常量，无法复用，有魔法值。
版本2：简单的变化开始
主题讨论：《从版本1到版本2中代码发生了非常巨大的变化，来说说你发现的巨大变化都有哪些，以及你能由此想到的更深入的知识点还有哪些？》
感受：第一反应差别不太大，但其实这一个小小的改变更多的是反应了人们思想上的巨大转变。具有了抽象的概念，通过变量的引用，将固定的值变为了可变的值，增加了代码的可复用性，变量可以灵活改变。
版本3：质的变化
主题讨论：《看到版本3之后，你想提什么样的问题？》
感受：第三版的出现，意味着什么？
版本4：变是永远不变的
主题讨论：《结合版本4的伪代码示例，对于版本4的命名：变是永远不变的，请你用不少于300字，来深入的探讨并描述一下你的感受》
感受：引用InputBox来接受数据，定义两个变量去接收用户输入的值，增大了代码的可用性、灵活性，满足了用户的需求，更加突出了抽象的思想。另外，魔法值没有了。设计一个系统要考虑到以后可能发生的各种情况，当然也包括各种数据的调用，计算等。为此，应尽量灵活的来表达，以适应系统以及用户操作的变化。
版本5：多此一举吗？
主题讨论：《看了版本5和版本4的代码示例，请用不少于200字，来描述一下它们之间这个巨大的变化》
感受：将print改为了msgbox，用弹框显示出数据，将打印方法进行了封装，提高了代码的复用性，使用户更清晰明了的看到运算结果。提升了用户体验，界面更友好，有了初步的前后端分离的概念。
版本6：用户的需求又来了
注意： 新增加的d值，需要从数据库中某个表里读取出来，再和a，b做运算。
主题讨论：《基于版本5的代码示例，用户又提出了新的需求（如版本6的代码示例），你帮忙想想，如何应对用户这种需求变化》
感受：将运算部分封装成具体实现类，通过方法调用实现。
版本7：用户的需求又又来了
主题讨论：《看了版本7的代码示例之后，发现程序员小哥硕果仅存的头发又少了，面对用户源源不断的需求变化，你作为一名高级软件工程师，该如何拯救这些代码？》
感受：使用设计模式
Ps：以上代码仅做展示，如工程项目还需补充代码注释和命名规范等。（VB版）
作业：请系统性的比较和分析“版本1”到“版本7”的演变过程，写一写你对软件设计（原则）的理解和认识。
1， 开放封闭原则
就是对扩展开放，而对修改封闭。其是所有面向对象原则的核心。软件设计追求的是易于扩展复用、封装实现细节、降低耦合度，开放封闭原则是实现这一目标的最直接的体现。（1）开放，对功能或需求的扩展开放，当有新需求或变化时，可依据现有的程序代码进行扩展，以便适应新要求；（2）封闭，意味着一旦设计完成，便可以独立工作，不能对其进行任何的修改。
2， 单一职责原则
很好理解，一个类只负责一项职责。针对一个类，其承担的职责越多，被复用的可能性就越小。如果类承担的职责很多，就意味着这些职责耦合在了一起，若其中一项职责发生变化，就可能会影响其他职责的处理。
3， 里式替换原则
里氏代换原则是由2008年图灵奖得主、美国第一位计算机科学女博士Barbara Liskov教授和卡内基·梅隆大学JeannetteWing教授提出，其严格的表述为：如果对每一个类型为S的对象o1，都有类型为T的对象o2，使得以T定义的所有程序P在所有的对象o1代换o2时，程序P的行为没有变化，那么类型S是类型T的子类型。这种描述让人非常难以理解，换一句更通俗易懂的解释就是：所有基类出现的地方，都可以使用子类进行替换，子类可以扩展父类的功能，但不能改变父类原有的功能。也就是说基类对象出现的地方，子类对象一定可以出现，但反过来则不行。比如我喜欢车子，那么意味着我喜欢自行车，但反过来就不一定，因为我喜欢自行车并不代表就喜欢所有的车子。
4， 接口隔离原则
有两项含义：（1）客户需要什么样的接口，就提供什么样的接口，不需要的就删除掉；（2）类之间的依赖关系应建立在最小的接口上。也就是说，接口中的方法要尽量的少，接口功能要尽量的细分。
5， 依赖倒置原则
依赖倒转原则就是要依赖于抽象，不要依赖于实现。高层模块不依赖于底层模块，二者都依赖其抽象；抽象不依赖于细节，细节应该依赖抽象。（Abstractions should not depend upon details. Details should depend uponabstractions.）要针对接口编程，不要针对实现编程。（Program to an interface, not an implementation.）也就是说应当使用接口和抽象类进行变量类型声明、参数类型声明、方法返还类型说明，以及数据类型的转换等。而不要用具体类进行变量的类型声明、参数类型声明、方法返还类型说明，以及数据类型的转换等。要保证做到这一点，一个具体类应当只实现接口和抽象类中声明过的方法，而不要给出多余的方法。
传统的过程性系统的设计办法倾向于使高层次的模块依赖于低层次的模块，抽象层次依赖于具体层次。倒转原则就是把这个错误的依赖关系倒转过来。
面向对象设计的重要原则是创建抽象化，并且从抽象化导出具体化，具体化给出不同的实现。继承关系就是一种从抽象化到具体化的导出。
抽象层包含的应该是应用系统的商务逻辑和宏观的、对整个系统来说重要的战略性决定，是必然性的体现。具体层次含有的是一些次要的与实现有关的算法和逻辑，以及战术性的决定，带有相当大的偶然性选择。具体层次的代码是经常变动的，不能避免出现错误。
从复用的角度来说，高层次的模块是应当复用的，而且是复用的重点，因为它含有一个应用系统最重要的宏观商务逻辑，是较为稳定的。而在传统的过程性设计中，复用则侧重于具体层次模块的复用。
依赖倒转原则则是对传统的过程性设计方法的“倒转”，是高层次模块复用及其可维护性的有效规范。
特例：对象的创建过程是违背“开—闭”原则以及依赖倒转原则的，但通过工厂模式，能很好地解决对象创建过程中的依赖倒转问题。
6， 迪米特法则
迪米特法则，也可称为最少知识原则。一个类对自己所依赖的类知道的越少越好，对于被依赖的类，不论其实现逻辑如何，都将这些逻辑封装在自己的范围内，对外通过public(protected可以通过子类访问)方法进行提供服务，否则不对外泄露任何信息，这也体现了数据保密性。
7， 组合/聚合复用原则
简单的说是，尽量使用对象的组合/聚合，而不是继承来达到复用的目的。
组合和聚合都是对象建模中关联关系的一种。聚合表示整体与部分的关系，表示“含有”，整体由部分组合而成，部分可以脱离整体作为一个独立的个体存在。组合则是一种更强的聚合，部分组成整体，而且不可分割，部分不能脱离整体而单独存在。在合成关系中，部分和整体的生命周期一样，组合的新的对象完全支配其组成部分，包括他们的创建和销毁。一个合成关系中成分对象是不能与另外一个合成关系共享。
组合/聚合和继承是实现代码复用的两种基本途径，在设计过程中尽量使用组合/聚合，而不是继承。因为继承使得基类与子类有较强的耦合性，通常情况下基类的内部细节对子类来说是可见的，这样基类的实现细节会暴露给子类，破坏了系统的封装性。
开闭原则是所有面向对象原则的核心；里式替换原则是实现开闭原则的重要方式之一；依赖倒置原则是系统抽象化的具体实现，其是面向对象设计的主要实现机制之一；接口隔离原则要求接口的方法尽量少，接口尽量细化；迪米特法则降低系统的耦合度，其使得一个模块的修改尽量少的影响其他模块，扩展会相对容易；在软件设计中，尽量使用组合/聚合而不是继承达到代码复用的目的。
关于设计原则的介绍有很多，在此推荐以下链接：
开闭原则：http://blog.csdn.net/lovelion/article/details/7537584
单一职责原则：http://blog.csdn.net/lovelion/article/details/7536542
里式替换原则：http://blog.csdn.net/lovelion/article/details/7540445
接口隔离原则：http://blog.csdn.net/lovelion/article/details/7562842
依赖倒置原则：http://blog.csdn.net/lovelion/article/details/7562783
迪米特法则：http://blog.csdn.net/lovelion/article/details/7563445
组合/聚合原则：http://blog.csdn.net/lovelion/article/details/7563441