仔细研究了一下一个日本公司做的一个项目的一部分的注释。将一些发现记录一下在此，欢迎版友们探讨、玩笑。

*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
TOT： the object that
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*

很多极其重要的，在我看来简直就是致命级别的类的设计，他们的注释都有或者都可以归结为 ??? that object that ??? 的句式（可以算句式？或者只能是个“半句式”？）。

//===================================
* ...
* ??? that object that ???
* ...
*/

这个句式我们先来做一个分析。为了方便，我们下文就用TOT来简称 the object that 这三个词。

*1 首先TOT的第一个词，也即是第一个T，是英语单词中的定冠词 the 。
*2 TOT的第二个词，也即是O，是英语单词中的object。这个词国内有译作对象，哲学上的“客体”也可以指这个。另外，在注释内（我看到的那些注释），也有 that static class that 的用法，这我们不妨也认为是一种 TOT 。
*3 TOT的第三个词，也即是第二个T，是英文单词中的连词 that 。

在注释中，the object which，也即是TOT的第三个词不是that，而是which，这时候实际上是TOW，我们在这里先不详细讨论 TOT 和 TOW 的区别，但是从我看到的那些注释来说，TOT通常是关于某一种，而TOW是可能有很多种中的一种。为了方便，我们不妨暂时认为 TOW 和 TOT 是某种程度上相当的，而且这里不讨论 TOW 。

一般地，TOT的第二个T后面接的是一个从句，而且这个从句修饰的是TOT中的第二个词，也即是“O”。

所以这样子的句式不是我们说的TOT：

Why was that？ == 比较明显，这个句子没有定冠词THE，也没有词汇object，而且这个that没有接从句。

That is also a determiner. == 这个句子第一个词不是the。这个句子有determiner这个可能可以表示客体的词，，没有出现object。这个句子的that也指向一个可能表示某个客体的东西，但是这个that不是一个连词而是一个代词，这个that并不是一个连词连着接一个修饰object的从句。这个句子也不是TOT。

The object is good but that another one is more better. == 这个句子出现了 TO，即前面两个词是 the object，但是接着没有再接一个 that，而是接了一个be+good。随后虽然出现了that，但是这个that前面有转折性的连词but，更严重的是，后面接着的不是一个定语从句，而是另外一个句子。这个句子不是TOT。

The object was created later that week. == 这个也有TO，但同样不是接着 that 和定语从句。再后来的那个that 实际上是限定词，所以这里也不是TOT。

Look at that guy。 == 不是TOT。

what's that you're writing == 不是TOT。

还有很多不是TOT的例子，暂时不讨论了。下面这些句子是TOT：

(1) the object that is red
(2) the object that is Michael
(3) the object that I wore
(4) the object that contains some apple
(5) the object that handles input data from keyboard and gamepad
(6) the object that is render to the screen
(7) the object that carries out graphics processing
(8) the object that always carries out graphics processing

注意到这些句子，第一个词都是定冠词the，第二个词都是词object，第三个词都是that，而且第三个词后面都是接着一个定语从句。这（1）~（8）都是TOT。

但是我们又可以将TOT分为两类（可能不完全）。注意看（1）~（3），这些TOT说明了the object的某种属性，特征，来源，为了方便，我们称这些TOT为TOT-1，并且称为“评判式的TOT”。相信大家也知道，这些TOT不一定没用，但是似乎很难说是什么设计思想的体现。

与之对比，我们看（4）~（8），这些TOT有都对the object的定位、特征、行为做出了某种规定。例如：

（4） the object that contains some apple
明确地说明了，the object包容了一些苹果。

（5） the object that handles input data from keyboard and gamepad
明确说明了，the object处理从键盘和游戏手柄的数据。

（6）……（8）也有对the object的定位、特征、行为做出了某种规定。为了方便，我们称这些TOT为TOT-2，并且称为“约化式的TOT”。

很明显地，我们可以看到，通过约化式的TOT，一个类或这个类的实例、对象的定位、特征、行为等等被规定了。这实际上也就意味着人对机器的受信或放权，进而也就是对软件的设计。例如：

the object that handles input data from keyboard and gamepad

这就等于在设计上建立了一个概念，有一个对象（一个类的对象，一个类），它处理从键盘和游戏手柄的数据。

(1) the object that is red —— TOT-1
(7) the object that carries out graphics processing —— TOT-2

从这里我们可以看出，对比TOT-1和TOT-2，我们可以发现：

（1） TOT-2可以直接划分、体现、确立系统（软件或硬件）中的类或对象的定位、特征、行为。
（2） TOT-1不能直接划分、体现、确立系统（软件或硬件）中的类或对象的定位、特征、行为，但可能对其也有影响或作用。

为了方面，下文我们主要讨论TOT-2，而且说TOT一般也是指TOT-2 。我们可以看到，TOT-2，正确地运用TOT-2以达到对系统的设计，似乎是理解科学的面向对象的程序设计的一个关键。

我们来开个玩笑，假设有个类

the object that let the guy who reply this post will have archived his little goal in 2021.

*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
TSCOAX ： the superclass of all x
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*

the superclass of all x 意味着这样子的一种设计：建立一个关于多种、多个事物 x 的超类。下面我们简称 TSCOAX，这里的T也是指the，这里的SC指super class，这里的O是of，这里的A是all，这里的x是某个名词。

设想这样子的一个类，比如叫做 Rectangle_Base，被这样子注释：

the superclass of all rectangle

考虑这个类有这些方法：

int getWidth();
int getHeight();
void drawToDisplay(int x, int y);

那么，凡是继承了这个类的 rectangle 类，比如说 FirstTypeRectangle，SecondTypeRectangle …… 由于继承，就都具有这些方法。由面向对象的特点，在不改写、重载的情况，我们很容易知道下面的命题是成立的：

?p(Rectangle_Base)∧?p(FirstTypeRectangle)∧?p(SecondTypeRectangle)……∧?p(……Rectangle)

换而言之，很简单的，我们使得所有的事物 x，在这里，是 Rectangle ，都具有了某种属性或方法，因为 TSCOAX 保证了所有的 X 都有一个共同的祖先超类。注意到，这实际上是一个自动的推广的过程，当我们使用 TSCOAX 设计了一个超类，超类的属性和方法就自动地推广到子类了，而不是一个子类一个子类地再实现某种属性或方法了。

换而言之，这是 TSCOAX 的第一个功能：建立了面向基于特征 q 的类集合 S(q) 的属性和方法 P 的全称命题：

? x , ( x ∈ S(q) => P(x) )

这是一个威力很大的功能。直观来看，由于 “the superclass of all x” 已经限定了 x 的超类必然有这个类，这就是使得严谨、完备地讨论所有的 x 成为可能。当然相应的，这也就使得讨论不相容与这个超类的 x 不可能（虽然在技术中可以 override 等等）。

TSCOAX 还有第二个功能，即连续使用 TSCOAX 可以更深入地建立事物的抽象。试考虑已经建立了：

Rectangle_Base # the superclass of all Rectangle

通过 TSCOAX ，我们考虑将 Rectangle 作为一种特殊的 Graphic，然后我们建立：

Graphic_Base # the superclass of all Graphic
∧ subclass(Graphic_Base) ∈ Rectangle_Base

在这里，我们把某种已经作为 superclass 的类，作为一种特殊的类，然后推定更抽象的超类，然后使用 TSCOAX ，这样就建立一个更深层面也更广泛的抽象。（如果这种概念是必要的而且正确的话。）

总结一下，TSCOAX 有两种功能：

（1） 建立关于特征的类的集合的全称命题。
（2） 产生更抽象的超类。

我们在上面只是看到了 TOT 的功能，却没有看到 TOT 的建立如何可能。经过 TSCOAX ，我们似乎已经有工具认识各种各样的超类，而如果一个类的超类已经确定了，这个类似乎也就确定了。

但是一个类的超类确立了，跟这个类的确定，实际上可能不是一件相等的事。甚至很多类没有什么超类。于是我们试着回到类的特殊性。

*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
TOTMHR ： the object that manage hardware, resource
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*

那些负责“管理”，特别是管理硬件或某种资源的类，似乎有特殊性，而且这种特殊性有着直接的要求：安全，速度。这样我们就看到了 TOTMHR ， 即 the object that manage hardware, resource 。这里的 M 是管理，这里的 H 是硬件，这里的 R 是资源。

实际上我们完全可以考虑这样子的类：

XXXManager # the object that manage XXX……

甚至运用 TSCOAX ，可以设计：

Manager_Base # the superclass of all class that manage something

但是这样子的设计似乎不见得有用。但是无论如何，如果设计上面这样子的 Manager_Base ，似乎就有给各种各样的 Manager 类划分、抽象、编码，等等了。

InputManager 在一些场景中是值得的。例如：

InputManager # the object that manage data from user input device

另外一些场景似乎也有 WindowManager，例如：

WindowManager # the object that manage all native window

显然，合理设计的 Manager 类和 XXXManager 类集，并不容易；更为困难的是，有的时候我们需要不要设计任何的 XXXManager 或者不要某种 XXXManager 。

如果一个 Manager 直接地管理硬件，或者某种资源，这样子的类如果有用，特别是作为全局性的、底层的抽象，似乎是一种省事的方法。毕竟，增删改查总是可以当做某种“管理”的，例如：

WindowManager : the object that manage all native window
∧ int createWindow(int x, int y, int background)
∧ int updateWindow(int windowId, const char* controll)
∧ int destoryWindow(int windowId)
∧ int queryWindowIfWithBackground(int background)

这种时候，假设 createWindow 返回的是一个新的 Window 的实例， WindowManager 就是一个 Window 类的工厂。

有的时候，我们不想或者工程上不适合做成工程，我们可以把 createWindow 改成 registerWindow ，例如：

WindowManager # the object that manage all native window
∧ int registerWindow(Window* x)
∧ int updateWindow(int windowId, const char* controll)
∧ int destoryWindow(int windowId)
∧ int queryWindowIfWithBackground(int background)

Window # the object that represent a window
^ Window(int x, int y, int background)
^ Window(int copyFromWindowId)

但是这样子有用吗？表面上，我们建立了一大堆非常正规化甚至“完整”的“数据图式”，但是容易证明，如果我们把面向对象等价于各种对象或者实体的增、删、改、查、记，我们只是把一切变成了“表格”，而且在查询表格而已……这不一定是错误的，我们实际上有没有真正提高工程的质量呢？

我们似乎有理由想想这样子的逻辑前提 t 是否存在：

t ：
    t.1表格是一切数据的自然形态;
    t.2对表格的增删改查记是一切软件的设计模式的最优形态。

如果t.1根本就不成立，似乎我们把一切但弄成“增、删、改、查、记”，不仅仅不科学，而且简直也不是一种合格的管理。这种时候，Manager成了一种几乎是感染了那种社会中的官僚主义、形式主义风气的东西。

如果t.2根本就不成立，似乎我们就有这样子的一个问题：软件的设计模式的最优形态，至少是软件的设计模式的当然形态，是什么样的？

*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
TOTS ： the object that _subjective_
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*

注意到这样子来问，我们实际上就把“软件”看成了某种可能具有某种定位、特征、行为的东西，我们就又回到了 TOT 。但是如果仅仅是 TOT ，我们似乎也就没有把问题推进一步。

但是我们的问题很明确了，那就是类的“设计”——这个设计的意思，其实就是这个类，怎么样，这个类作为某种主体、实体，具体怎么样。这个类是具有某种特殊的点的，而通过 TOT 后面的从句，这个类被主体地主动地建立起来。于是我们看到了，就特殊性来看，TOT 的设计转换到了 TOTS ： the object that _subjective_ 。

我们回到注释的例子。一种常见的方法是使用动词，例如：

(4) the object that contains some apple
(5) the object that handles input data from keyboard and gamepad
(6) the object that is render to the screen
(7) the object that carries out graphics processing
(8) the object that always carries out graphics processing

在（4），这里建立一个关于object的概念，在这种概念里，这个object主要的是"contains some apple"，动词是"contains"。

注意到从 （i）the object that 到 （ii）the object that contains some apple 的具体化。在 （i） 那里，类的定位、特征和行为的规定似乎有了一种动力，但是还没有展开或者说完成。而在（ii），这个类的意义和具体的参与到这个软件（系统）的方式也就确定了。

现在很多的编程教程有“容器类”的说法。容易想到，the object that contains ……，某种程度上就是这个类是一个容器的意思。而  the object that contains some apple ，这里的 some apple 作为 contains 的宾语，就有这个容器类里面所“contains”的内容是什么的意思。

又注意到（5）the object that handles input data from keyboard and gamepad，这里的动词是“handles”。但是这里的handles 是什么意思呢？是不是“句柄类”的意思呢？

在实际的代码中，这个“the object that handles input data from keyboard and gamepad”的类，并不是作为某种“回传句柄”，这里的handles仅仅是处理某种东西的意思。

作为对比，如果一个类主要是是“contains some thing w”，和这个类主要是“handles some thing w”，显然行为差别很大，而且仅仅将此理解为“增删改查记”，可能也没有帮助我们更深刻地或者更高先进地完成软件的设计、系统的功能，等等。反过来，我们的意思也不是一定按“contains some thing w”和“handles some thing w”那样去设计就更良好，在这里我们似乎只能谈到，就软件的工程化来说，我们可以通过动词去划分、理解、组织，进而可能才是真正的管理真正的“软件工程”。

在（6）（7）（8）中，都体现了 TOTS 的某种具体形式。在（6）中，从这个类是要被渲染到屏幕，这个方面来理解这个类。在（7）（8），通过carry out说明这个类负责的是什么，而且（8）还有“always”的副词。

注意到，在这些方法中，我们已经将自己的经验“注入”到软件和软件的行为之中，软件被软件的设计师、工程师“人化”了。

由此我们可以得到这个结论：

通过具体化的 TOTS ，例如动词化的，谓语宾语化的，系表结构的，带副词的谓语宾语化的，等等主体化、主观化的 TOTS ，可以进一步设计类和对象，使得对象“人化”。

一种特别的角度，如果我们从权利/义务/责任的角度来考虑这种“人化”，例如下面这里这种 TOTS ：

the object that printing on the canvas
the object that return information of price
the object that keep cache

我们似乎就将软件和软件的行为“权利化/义务化/责任化”了。

还有一种角度，如果我们以未来时来考虑，例如下面这种 TOTS ：

the object that will return the latest weather news

这样子，这个类在设计上就承担着某种未来要如何如何的规定，这个类实际上被“未来化”了。

所以：

（1） 通过对 TOTS 的具体化，类和对象，软件和软件的行为被人化，被权利化/义务化/责任化。
（2） 即时时间还未过去，通过包含将来时的 TOTS，类可以被规定未来的行为，类被未来化。

关于 TOTS ，我们先讨论到这里。

*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
TOTC ： the object that contains ...
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*

我们来深入地讨论一下一种 TOTS 。即 TOTC ： the object that contains ... 一种以包含某种东西为具体化的对象。

通过 TOTC ，类被确定为某种事物的“容器”。在实际上，这种的类通常还有一下的特点：

（1） 包含的不仅仅是一个数据，而是多个数据。
（2） 有某种可以遍历每个数据的方式。
（3） 可以批量地创建多个，而每个创建的容器实例，又可以继续包括多种数据。

我们可以看到，容器类具有一种特点，他实际上使得复杂的、海量的数据，可以通过某种方式被组织起来。而通过多个的容器，多个不同阶段的容器，多个不同权限的容器，管理复杂的数据结构可能也就有了优势。

以我们人类来对比，我们人类很难“横扫千军”，但是计算机做for循环，做遍历，这些都是时间很稳定，而且实际上很可能少于1ms就可以访问远远不止成千上万的数据。（虽然软件很差或者其他什么原因，这不一定总是可能）。

（1） 包含的不仅仅是一个数据，而是多个数据。 —— 这就意味着可以对批量的数据做批量的操作，这就意味着可以充分通过数据的集中来实现某种目的。

（2） 有某种可以遍历每个数据的方式。—— 这就意味着，所有已经可以被索引的数据，都能有某种访问、调出、修改的方式。（除非某种原因不具有可写性）

（3） 可以批量地创建多个，而每个创建的容器实例，又可以继续包括多种数据。—— 这就意味着，可以通过人工的干预，使得这种对数据的管理也是有层次的。

由于 TOTC 用的是比较多的，在此我们就不谈论太多了。实际上，数据结构的意思，一个重大的方面就是容器型的数据结构，以管理容器中的数据。

*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
TOF ： the object for ...
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*

我们知道，原来有“第五代程序设计语言”的说法。在一个时期，这种想法被认为“已经证明了是失败的”。但是我们注意到，我们从 TOT 到 TSCOAX 到 TOTMHR 到 TOTS 到 TOTC ，这些注释所关注的，或者说切入的方式，实际上还是“什么”，是“意义”，而不是“目的”。

有一种注释是这样子写的：

the object of ……

这里的 TOO ，已经很明显地反应了，那种人类将软件和软件的行为作为自己的工具的逻辑了。与这种逻辑相对的，被注释为 the object for ... 的。在 TOF 中，软件被规定为自己去参与、实现某种目标、实体。例如这些：

the object for a picture
the object for a map
……

遗憾的是，从代码来看，这些 TOF 仍然只是某种“封装”，虽然已经体现了以类为实现某种目的的中介的行动。随着计算机的发展，未来的计算机上会不会出现这样子的类呢？

the object for recommendation
the object for money gaining
the object for human safe
the object for world peace

总的来说，我对这些方面还是乐观的，但是似乎也需要审慎。

*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
总结
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*

从 TOT 开始，我们具体地、特殊地讨论了 TSCOAX ， TOTMHR ， TOTS ， TOTC， TOO， TOF 这六种注释的句型，这六种句型的设计思想，他们的能力，从抽象到特殊到抽象又回到特殊地讨论了这7位面向对象中的“T先生”。

软件和软件的行为是可以被规定和设计的，在当代的面向对象的程序设计中，多种多样的逻辑和模式被运用到软件的工程化和工程化了的软件之中。

先说到这里。
--
修改:darkk FROM 223.104.44.*
FROM 118.26.128.*