从vb6.0学习完并且做完一个项目之后，又开始正是的接触了完全面向对象的语言vb.net，首先从本质上来说，进入vb.net的学习以后就开始了另外的一种编程思想，不是说在vb6下没有这种思想，而是不完全的。
在vb6中虽说也是要面向对象，所有的控件，所有的窗体都是一个对象，但是涌来的时候并不是那个么的彻底，因此vb.net下就完全进入了面向对象的世界。
对比vb6和vb.net：
细数vb6中的那些个东西，无外乎是一些基本的数据类型，一些基本语句，还有一些对象，当然了也少不了常用的api函数，还有第三方的控件。其实没多少东西。
再说到了vb.net下，也就是vb6的一个扩展，有了比vb6更强大的思想（也就是完全面向对象），有了一个相当庞大的框架，还有一个更加智能的IDE。除了这些还有别的吗？（暂时想不起来了）
在进入完全面向对象的世界之后，有了面向对象的三大特性：封装、继承和多态。那就不得不说到由这些特性所衍生出来的一些牛人在软件开发和设计时常用的一些开发模式，经前人总结之后形成了设计模式。
从上向下看设计模式，首先从整体上划分，设计模式可以划分为创建模式、结构模式和行为模式。
创建模式：对类的实例化过程的抽象化。一些系统在创建对象时，需要动态地决定怎样创建对象，创建哪些对象，以及如何组合和表示这些对象。创建模式描述了怎样构造和封装这些动态的决定。包括：简单工厂模式、工厂方法模式、抽象工厂模式、单例模式、多例模式、建造模式、原型模式等。
结构模式：描述如何将类或者对象结合在一起形成更大的机构。结构模式描述两种不同的东西：类与类实例。包括：适配器模式、合成模式、装饰模式、代理模式、享元模式、门面模式、桥梁模式等。
行为模式：是对在不同对象之间划分职责和算法的抽象化。行为模式不仅仅是关于类和对象的，而且是关于它们之间的互相作用的。包括：策略模式、模板方法模式、观察者模式、迭代子模式、责任链模式、命令模式、备忘录模式、状态模式、访问者模式、解释器模式、调停者模式等。。
好了，模式的分类也就这些了。个人感觉这些模式也不是说有严格的区分的，因为模式就是面向对象特性的有序组合，因此其中有些模式都是在另外一个模式至上提炼或者说是抽象出来的。并且有些模式还十分相似比如说：适配器模式和桥接模式。但是这两者又有不同的应用范围。
所以再回过头看《大话设计模式》时，看到作者写的这些话觉得很贴切：
设计模式有四境界：
1. 没学前是一点不懂，根本想不到用设计模式，设计的代码很糟糕。
2. 学了几个模式之后，很开心，于是到处想着要用自己学过的模式，于是时常造成无用模式而不自知；
3. 学完全部模式时，感觉诸多模式及其相似，无法分清模式之间的差异，有困惑，但深知误用之害，应用之时有所犹豫；
4. 灵活应用模式，甚至不引用具体的没肿模式也能设计出非常优秀的代码，已到达无剑胜有剑的境界。
到此可以看出来设计模式就是一个思想，从无到有，再到无。那么既然是思想就要用某种方式表达出来。当然了代码也可以表达某种设计模式，但是阅读代码毕竟是不太直观。因此还得说道UML
UML（Unified Modeling Language），统一建模语言，可以以图形的方式来表达出设计者的思想，也可以很方便的表达出设计者所采用的设计模式。不过UML并不仅仅如此，还有更强大的功能。那就是对系统进行概念性的建模，也就是在系统未进行开发之前就可以对系统进行整体模型的建立，这样就很有助于在开发前对系统进行一些评估。
既然uml称为统一建模语言，作为语言自然是供人交流的。并且统一语言，也成为开发人员之间进行无障碍交流的语言。
还有一点很重要的是uml的正向工程和逆向工程，不过这不是说uml本身具有这样的功能，而是可以使用某一工具通过uml来生成编程代码。这对与提高开发效率来说是很有帮助的。
再细说UML，UML中有视图和图两个层的概念。视图是由多个图构成。
UML中有9种图：
l 类图(Class Diagram)，描述系统的静态结构；
l 用例图(Use Case Diagram)，描述系统功能；
l 对象图(Object Diagram)，描述系统的静态结构；
l 时序图(Sequence Diagram)，按时间顺序描述系统元素间的交互；
l 协作图(Collaboration Diagram)，按照时间和空间顺序描述系统元素间的交互和他们之间的关系；
l 状态图(State Diagram)，描述了系统元素的状态条件和响应；
l 活动图(Activity Diagram)，描述了系统元素的活动；
l 组件图(Component Diagram)，描述了实现系统的元素的组织；
l 配置图(Deployment Diagram)，描述了环境元素的配置，并把实现系统的元素映射到配置上。
在按照视图来分又分为五种视图：
l 用例视图(Use Case View)，强调从用户角度看到的或需要的系统功能，是被称为参与者的外部用户所能观察到的系统功能的模型图。
l 动态视图(Dynamic View)，体现了系统的动态或者行为特征，也称为行为模型视图(Behavioral Model View)或并发视图(Concurrent View)。
l 逻辑视图(Logical View)，展现系统的静态或结构组成及特征，也被称为结构模型视图(Structural Model View)或者静态视图(Static View)。
l 组件视图(Component View)，体现了系统实现的结构和行为特征，也称为实现模型视图(Implementation Model View)。
l 配置视图(Deployment View)，体现了系统实现环境的结构和行为特征，也被称为环境模型视图(Environment Model View)或者物理视图(Physical View)。
再说关系，分为泛化（继承）、组合、聚合、关联、依赖（由强到弱排序）
由UML中的这些元素，就可以来表示开发过程中的一个思想，还有实现。
但是再想想，非得有这些元素吗？不能多也不能少吗？这是一个追根溯源的问题。不过这也是一个为什么的问题。为什么要有uml，为什么是这样的uml？百科：UML
说完UML接着再来说数据库，说实话当时看数据库的时候并不是很懂，这导致好多东西没有印象，这导致到现在用数据库的时候只知道一些简单的应用。
数据库分为关系型数据库和非关系型数据库，对于非关系型数据库至今还没有接触过。关系型数据库，就是将有关联的数据按照某种方式有序的存放到数据库中存储。
关于这块的总结我想还得再回头把数据库再学学才能有所沉淀。
以上的这些东西其实都是在软件工程之内的，因此再说软件工程。说到软件工程，就得说软件整体的架构，于是就联想到mvc架构以及将软件分层的设计思想。这些也是软件生命周期中十分重要的一个环节，因为这涉及到软件的维护，还有扩展。
从问题定义、可行性研究，再到需求分析，概要设计，一直到最后的软件交付，再到软件“死亡”。这样就是一个完整的生命都是由前面的那些内容来填充的，当然了，除了那些还有其他的内容。
对于一个从事软件开发行业的人来说，软件工程可以说是你一生都在实践的东西。
就这么多了吧，没思路了。。。