电子工程师技术服务社区
- 社区
- 论坛
- 综合技术专区
- 面向对象裸程序的例子≡显示器控制程序[连载四]
面向对象裸程序的例子≡显示器控制程序[连载四]
-
-
US
- LV5工程师
-
| 2016-03-31 18:39:18
- 浏览量 462
- 回复：0
对于对象能力的定义，我们一般可以从重要的入手，然后慢慢地展开，把所需要的其他能力逐渐归纳为函数，从而把面向对象的思想发展下去。上帖我们提到了三个函数是怎么来的，还没有涉及到函数的任何实质，那么本帖就探讨一下这三个函数的实质性规划与设计。
有了功能要求，我们就要实现它，在裸程序中，实现它的一个首要任务，就是要进行数据传递方式的设计。很显然我们必须要有一个显示区域，来存放我们所要显示的内容，以及显示内容的显示属性，我们还要规划这个显示区域到底要显示多少多少字符或者是点阵。但是由于我们事先并不知道我们的显示设备一次会提供多少显示量，所以我们可以把显示区域的内存，也就是显存，定义得大一点，以至任何一款符合设计要求的显示器都能得到满足，这样的做法在裸编程中其实还是比较实用的，因为裸编程中我们很少去申请动态的空间，程序设计完，所有的变量位置皆已确定，行就行，不行编译就过不去，所以我们可以通常选择一些内存资源比较丰富的新款单片机。
但是这样的做法也有一个弊端，比如当我们预先估计不足而导致数据空间不够的时候，我们就得从头来改这个显存的大小，从而导致整个显示程序都要相应的产生一些变动，这还不是最糟糕的，最糟糕的是当一款新的显示器因为新的功能需求而导致数据结构需要发生变化的时候，我们就崩溃了，前期的工作可能改动就非常大，甚至于都要重新过一遍，也就是重写重调，这么痛苦的事情，我是最讨厌的了。
所以我们要尽量避免这类事情发生，这里对面向对象的思想，就颇为需求了。这个时候，我们就要引入一个新的概念，那就是对象的儿子，子对象。前面讨论的，其实都只是一个抽象的对象，没有任何具体的样子，而只是笼统的规划了所有的显示器必须具有什么能力，而对于每一个具体的显示器来说，还没有任何具体的设计，在这里，每一个具体的显示器，就是显示器对象的子对象，他们形态各异，但是都必须能完成规定的功能。以传统的OOP语言理论来说，这里就产生了一个继承的关系，但是在裸程序思想里，我并不赞成引入这个概念，因为传统的OOP语言里的继承，纯粹是一个语法上的逻辑关系，继承关系明确，而裸程序中的这个思想，并没有任何语法支持，继承关系就非常微弱了，还不如说是归类与概括。但无论是什么关系，我还是不想就这种一目了然的关系弄个新名词来，让看的人费解。
既然引入了子对象，我们能看出这种做法有什么实际意义吗？也许有经验的资深程序员能看出来。我们在做父对象数据设计的时候，我们并不规定具体的数据格式和显存大小，而是一股脑儿地全推给子对象自己去搞，父对象什么都不管。哈哈！这样做事情真是很简单吧？不是我的事情我不管，不要说我偷懒，因为站在父对象的角度讲，这是最明智的做法，因为管不了，所以不管。
到这里也许就会产生更多的疑问了，一个对象什么都不管，那作为调用者怎么使用这个对象呢？你想用它，它什么都不管，这怎么行呀？别着急，父对象不管的，是那些具体的事情，抽象的事情，还是管的，要不然它就没有理由存在了。你抱怨了，说明你在思考，既然思考了，就把思考的问题提出来，提出来的，就是我们设计父对象的依据。提问题，我想这比搞程序要简单得多，比如：显示器能显示多少乘多少的字符？颜色是多色还是单色？显示模式是否支持预定的方式（如移动、闪烁等）？工作模式是图象还是字符？等等，这里附加说明一下，对于显示模式，我们这里都以字符显示为例，既然是面向对象的思想，相信扩充出图象显示模式，还是很容易的事情。
有问题出来了，我们就继续为它添加代码好了。
dispGetMaxCol(); // 取一行最多有多少列
dispGetMaxRow(); // 取显示器一共有多少行
dispGetMaxColors(); // 取显示器最多有多少色
dispSetShowMode(); // 设置显示的方式，对于不支持的显示方式就自动转为正常显示
dispSetWorkMode(); // 设置工作模式，如果没有的模式就返回0，支持的就返回1
对于这些函数的定义，各人可以根据自己的习惯来设置，我只是临时弄了这个例子，未必就是最好的，我的目的是重在说明思想。我也害怕把程序弄得庞大了，出本书都嫌厚。
似乎加了这些函数之后，我们根本就没看到显示数据的具体形式，和前面的函数一起，都并没有什么明确的说法。这种感觉很正确，我们确实没有对显存做任何定义，但是似乎功能却都已经定义了，其实也确实是定义了，而且将来我们就这样用，而且也不用怕，程序一定会写完的。
对于对象能力的定义，我们一般可以从重要的入手，然后慢慢地展开，把所需要的其他能力逐渐归纳为函数，从而把面向对象的思想发展下去。上帖我们提到了三个函数是怎么来的，还没有涉及到函数的任何实质，那么本帖就探讨一下这三个函数的实质性规划与设计。
有了功能要求，我们就要实现它，在裸程序中，实现它的一个首要任务，就是要进行数据传递方式的设计。很显然我们必须要有一个显示区域，来存放我们所要显示的内容，以及显示内容的显示属性，我们还要规划这个显示区域到底要显示多少多少字符或者是点阵。但是由于我们事先并不知道我们的显示设备一次会提供多少显示量，所以我们可以把显示区域的内存，也就是显存，定义得大一点，以至任何一款符合设计要求的显示器都能得到满足，这样的做法在裸编程中其实还是比较实用的，因为裸编程中我们很少去申请动态的空间，程序设计完，所有的变量位置皆已确定，行就行，不行编译就过不去，所以我们可以通常选择一些内存资源比较丰富的新款单片机。
但是这样的做法也有一个弊端，比如当我们预先估计不足而导致数据空间不够的时候，我们就得从头来改这个显存的大小，从而导致整个显示程序都要相应的产生一些变动，这还不是最糟糕的，最糟糕的是当一款新的显示器因为新的功能需求而导致数据结构需要发生变化的时候，我们就崩溃了，前期的工作可能改动就非常大，甚至于都要重新过一遍，也就是重写重调，这么痛苦的事情，我是最讨厌的了。
所以我们要尽量避免这类事情发生，这里对面向对象的思想，就颇为需求了。这个时候，我们就要引入一个新的概念，那就是对象的儿子，子对象。前面讨论的，其实都只是一个抽象的对象，没有任何具体的样子，而只是笼统的规划了所有的显示器必须具有什么能力，而对于每一个具体的显示器来说，还没有任何具体的设计，在这里，每一个具体的显示器，就是显示器对象的子对象，他们形态各异，但是都必须能完成规定的功能。以传统的OOP语言理论来说，这里就产生了一个继承的关系，但是在裸程序思想里，我并不赞成引入这个概念，因为传统的OOP语言里的继承，纯粹是一个语法上的逻辑关系，继承关系明确，而裸程序中的这个思想，并没有任何语法支持，继承关系就非常微弱了，还不如说是归类与概括。但无论是什么关系，我还是不想就这种一目了然的关系弄个新名词来，让看的人费解。
既然引入了子对象，我们能看出这种做法有什么实际意义吗？也许有经验的资深程序员能看出来。我们在做父对象数据设计的时候，我们并不规定具体的数据格式和显存大小，而是一股脑儿地全推给子对象自己去搞，父对象什么都不管。哈哈！这样做事情真是很简单吧？不是我的事情我不管，不要说我偷懒，因为站在父对象的角度讲，这是最明智的做法，因为管不了，所以不管。
到这里也许就会产生更多的疑问了，一个对象什么都不管，那作为调用者怎么使用这个对象呢？你想用它，它什么都不管，这怎么行呀？别着急，父对象不管的，是那些具体的事情，抽象的事情，还是管的，要不然它就没有理由存在了。你抱怨了，说明你在思考，既然思考了，就把思考的问题提出来，提出来的，就是我们设计父对象的依据。提问题，我想这比搞程序要简单得多，比如：显示器能显示多少乘多少的字符？颜色是多色还是单色？显示模式是否支持预定的方式（如移动、闪烁等）？工作模式是图象还是字符？等等，这里附加说明一下，对于显示模式，我们这里都以字符显示为例，既然是面向对象的思想，相信扩充出图象显示模式，还是很容易的事情。
有问题出来了，我们就继续为它添加代码好了。
dispGetMaxCol(); // 取一行最多有多少列
dispGetMaxRow(); // 取显示器一共有多少行
dispGetMaxColors(); // 取显示器最多有多少色
dispSetShowMode(); // 设置显示的方式，对于不支持的显示方式就自动转为正常显示
dispSetWorkMode(); // 设置工作模式，如果没有的模式就返回0，支持的就返回1
对于这些函数的定义，各人可以根据自己的习惯来设置，我只是临时弄了这个例子，未必就是最好的，我的目的是重在说明思想。我也害怕把程序弄得庞大了，出本书都嫌厚。
似乎加了这些函数之后，我们根本就没看到显示数据的具体形式，和前面的函数一起，都并没有什么明确的说法。这种感觉很正确，我们确实没有对显存做任何定义，但是似乎功能却都已经定义了，其实也确实是定义了，而且将来我们就这样用，而且也不用怕，程序一定会写完的。
