lbaihao的专栏

实际工作时cal.c是直接完成工作的，但是cal.c中的关键部分是调用的framework.c中的函数来完成的。第三：分层写代码的思路是：有多个层次结合来完成任务，每个层次专注各自不同的领域和任务；并且把相应的接口写在对应的头文件中发出来，将来别的层次的人用这个头文件来协同工作。第六：下层注重实际干活的函数，注重为上层填充变量，并且将变量传递给上层中的函数。第五：上层注重业务逻辑，与我们最终的目标相直接关联，而没有具体干活的函数。第四：分层之后上层为下层提供服务，上层写的代码是为了在下层中被调用。...

平时阅读一些远吗分析类文章或是设计应用架构时没少与UML类图打交道。实际上，UML类图中最常用到的元素五分钟就能掌握，下面赶紧来一起认识一下它吧：一、类的属性的表示方式在UML类图中，类使用包含类名、属性(field) 和方法(method) 且带有分割线的矩形来表示，比如下图表示一个Employee类，它包含name,age和email这3个属性，以及modifyInfo()方法。那么属性/方法名称前加的加号和减号是什么意思呢？它们表示了这个属性或方法的可见性，UML类图中表示可见性的符.

监听者对大家来说可能并不陌生，所谓监听者就是用来监听自已感兴趣的事件的，当收到自已感兴趣的事件时会做出相应的反映。    它的应用是非常广的，比如win32的消息机制，它跟监听者模式就异曲同工，操作系统将产生的各种事件包装成消息(msg),该消息结构包装了发生的事件的描述信息，比如消息值，屏幕坐标等，然后将它投递到相应的进程中，当该进程收到该消息时会查看该msg结构中的信息，也就知道了发生了什

前言：        关于各种语言孰优孰劣的讨论在软件界就是个没完没了的话题，今天我决定也来掺和下。不过我想探讨的不是哪种语言的性能如何，钱途如何，而是站在语言本身特性的基础上中肯地比较探讨。因为现在工作用的是C/C++, 以前接触过Java，于是我就以这两门语言作为我的对比语言。本文目的：        我就以监听器的实现为例演示各自的实现代码，认识下Java与C++

监听者对大家来说可能并不陌生，所谓监听者就是用来监听自已感兴趣的事件的，当收到自已感兴趣的事件时会做出相应的反映。    它的应用是非常广的，比如win32的消息机制，它跟监听者模式就异曲同工，操作系统将产生的各种事件包装成消息(msg),该消息结构包装了发生的事件的描述信息，比如消息值，屏幕坐标等，然后将它投递到相应的进程中，当该进程收到该消息时会查看该msg结构中的信息，也就知道了发生了什

C到C++，它们的关系演变过程是怎样的。从Linux的内核代码里面你可以了解到更深的编程层次的面向对象，而不是简单的封装、继承、多态。首先这个题目有点大，而且过于深，而我能了解到的也只是冰山一角，不过我觉得能去做这样的一种有意义的工作，对于提升自己来说，也是很有帮助。主要分以下几部分：引言。C语言中的封装、继承与多态。从Linux体系设备驱动模型（d

解决的问题：我们PC用到的文件系统，其实就是我们数据结构里的树形结构，我们处理树中的每个节点时，其实不用考虑他是叶子节点还是根节点，因为他们的成员函数都是一样的，这个就是组合模式的精髓。他模糊了简单元素和复杂元素的概念，客户程序可以向处理简单元素一样来处理复杂元素,从而使得客户程序与复杂元素的内部结构解耦。将对象组合成树形结构以表示“部分-整体”的层次结构。组合模式使得用户对单个对

桥模式，其作用就是让抽象与实现相分离，让两者都能够各自变化。举例来说吧，画图，我可以画矩形，圆，三角形等等，在哪里画呢？我可以在pdf上画，也可以在doc上面画。画什么图和在哪里画都是可以独立变化的，此种情况就比较适合用桥模式。就是说设计中有超过一维的变化我们就可以用桥模式。如果只有一维在变化，那么我们用继承就可以圆满的解决问题。 我的图形定义： [cpp]

概述想想我们小时候玩的四驱车，里面的构造很复杂，马达，舵机，电池组等等，而我们控制它却非常简单，只要打开电池开关，他就可以跑。我们其实不用知道它里面是如何工作，只要知道拨动开关它就可以工作就行了，这个开关其实就四驱车给我们的一个友好的组件，使得我们可以很方便的控制它。外观模式其实定义了一个高层接口，该接口为子系统中的一组接口提供一个一致的界面，使得这一子系统更加容易使用。类图和

解决的问题：适配器模式把一个类的接口变换成客户端所期待的另一种接口，从而使原本接口不匹配而无法在一起工作的两个类能够在一起工作。比如说我的hp笔记本，美国产品，人家美国的电压是110V的，而我们中国的电压是220V，要在中国能使用，必须找个变压器转一下电压才可以。这个变压器就是个适配器。适配器模式有类适配器和对象适配器两种模式，我们将分别讨论。类适配器：

解决的问题：我创建的这个对象比较复杂，且该对象里面的成员函数用不同的实现来表示不同的实例，换句话说就是同样的对象构建过程可以有不同的表示。比如我那天去吃过桥米线，他们有不同的套餐，套餐里包含的种类是一样的，都有一碗米线，一份凉菜，一杯饮料。但是不同的套餐里这3样又都不是全部一样的。此时我们就可以用建造者模式。类图结构：1．建造者（Builder）

1、策略模式在策略模式中，我们可以定义一些独立的类来封装不同的算法，每一个类封装一种具体的算法，在这里，每一个封装算法的类我们都可以称之为一种策略(Strategy)，为了保证这些策略在使用时具有一致性，一般会提供一个抽象的策略类来做规则的定义，而每种算法则对应于一个具体策略类。策略模式的主要目的是将算法的定义与使用分开，也就是将算法的行为和环境分开，将算法的定义放在专门的策略类中

观模式是为了解决类与类之家的依赖关系的，像spring一样，可以将类和类之间的关系配置到配置文件中，而外观模式就是将他们的关系放在一个Facade类中，降低了类类之间的耦合度，该模式中没有涉及到接口，看下类图：（我们以一个计算机的启动过程为例）我们先看下实现类：[java] view plaincopypublic class CPU

1. 产品需求定义产品需求定义的目标是：“清楚地描述要做的产品是什么样的？不涉及具体实现方法。”，其定义过程如下图所示。  此产品需求定义包括：软件+硬件。 2. 结构化设计方法的基本思路    按照需求，将软件逐级细化，分解为不必再分解的的模块，每个模块完成一定的功能，为一个或多个父模块服务（即接受调用），也接受一个或多个子模块的服务（即调用子模块）。模块的概念，和编程语