毕业感言 （有红包）毕业纪念+闲聊（中二）

[houyanjie]

于 2019/12/12 于 PM2点44分, Mr.K 018 说道:

毕业纪念+闲聊（中二）

今天(指12月12号，不用在意我为什么要强调这个)就算是毕业+穿越了，可以自由地探索大人的世界了√

这里感谢字母大佬 @Κris 陪我版聊（a.k.a.水贴），新人们想要更快地穿越/出村，就去找她版聊吧！毕竟字母酱的水量是完全可以保证的字母大佬还是非常和善的，新人们不用害怕，乖乖成为她的惹不起吧~

19/12/14更新：据说字母大佬当动漫区管理才一年多，就已经有了183K的节操，平均每天能氵501.03点节操

——对，全是回帖回出来的节操

所以说，只要肯水肯版聊，三天穿越不是梦！不，一天穿越也不是梦！

 

初来乍到，也不知道该说点啥，不然就聊聊我一年前的中二世界观吧。大家如果有兴趣就随便看看，要是嫌太长不看的话，就拿了红包再走吧~
本文可能比较长，为防止疯狂下拉找文章结尾，这里先说一嘴：红包口令不出意外是“你说这些谁听得懂啊”。如果口令不对或者根本没有什么红包，请艾特我修改（指修改帖子正文），万分感谢

那么话不多说，开始正文(?)

0 缘起

这个中二世界观的起源是一年前的某一节马原课。众所周知马原前一半都是哲学，而且🐎院老师跟工科学生天然相性就不太合（你作为马院老师不懂牛二不怪你，但是明明不懂还要拿出来瞎扯就是你的错了），于是我和我的某个舍友就开始坐在第一排交头接耳，而且根本没有控制音量，老师绝对听得见（笑），作为对老师瞎扯的某种抗议。
后来，除了我俩之外就没人坐第一排了

那么，我们都交头接耳些了什么呢？

1 论计科学生如何回答哲学问题

这一天老师讲到哲学史上有名的“特修斯之船”问题。这个问题比较经典，这里就不赘述了，不了解详情的朋友请百度。基本上正常人的答案都是那个一直叫特修斯之船的才是真正的特修斯之船咯，但是为啥呢？
按照马原的原理（其实现在有点记不清了，欢迎考研大佬斧正）当然是整体大于部分之和balabala，但是我们是CS（计科的简写）学生欸，我们下意识地就要搞明白“整体不是部分之和是什么”这个问题。

回到船本身上来。组成船的材料大概有木板，钉子，绝缘漆啥的，为了简便起见我们不妨假设造船光靠木板就行。显然，不是说光有合适材料和形状的木板就是一条船了，各个木板还要处在正确的位置上才行。换而言之，木板和木板间需要有正确的相互关系才行。比如构成船壳的木板间要求水密，船的骨架间则要求连接很坚实，不易断裂（当然，前提是它们之间需要有“互相连接”这个关系，不然一切都是扯淡）。于是，船的各个部分各自连接起来相互关联了起来。

本来到这里已经可以写Q.E.D.了。但是我们实在无聊，横竖看了半节课，看出来字缝里满满地写着数据结构里面的“图”。

2 “图”

计科专业的朋友，码农，或者了解过数据结构的朋友可以跳过这一小节。

想要查看关于“图”地更严格的定义，请参阅百度百科或者随便哪一本离散数学书。

各行各业都有黑话。雨果在《悲惨世界》中专门花了一小节来讲各种黑话——文雅一点的表示是“切口”——各种语言的黑话，各行各业的黑话，还有文人雅士的黑话。当然我们不探讨雨果想表达的深层意思，至少我们知道了黑话是到处都有的。

写程序的家伙们也有黑话。实际上，这帮家伙日常说的话里面充满了黑话。程序员们说“对象，实例，成员，方法，函数，构造，析构”，等等等等。“图”，就是他们说的黑话。

想象一张简单的地图。地图上面有几个村子和几座小镇，有公路连接，并且这些路都是不相交的。如果我们不太在乎路具体经过哪里，只关心从A村到B小镇有没有公路相连，怎么沿着公路走，那么我们干脆把公路去曲而取直，或者干脆不在乎这条“路”到底是曲线还是直线，只要在两个镇子/村子间随便连一条线，就表示它们之间有一条路啦。这样画的线，叫做图上的“边”。当然，可以对边逐个标号，这样就能区分哪条边对应哪条路了。

我们甚至可以更进一步，现在我连镇子/村子具体坐落在哪里、有多大也不想知道了，只要它们之间连接着的路的情况不变就行。那么我们干脆就把这些镇子或者村子画成一个点，叫做节点/结点。如果有路（到这里变成了一条边）通向这里，那就把边的末端连在这里好了。同样，我们不在乎这个点画在哪里，只要连接路面的情况相同就行。同样，可以对点标号，来区分这个点代表哪个村庄或者镇子。
同样，如果路面相交，我们为什么不把十字路口也当成一个点，跟镇子或者村子同样对待呢？

好了，现在你已经成功地把实际的地图抽象成了程序员嘴里的黑话“图”了。当然，图上的节点不一定非要代表村庄或者集镇，只要是能互相区别的东西就行；边也一样，不一定非得表示道路，只要是某种关系就行。比如说，讨论人际关系是，个人可以当作图上的节点，而被讨论的那种关系就是图上的边。在前文的特修斯之船问题中，节点就是各种木板，边就是木板之间的关系——当然不限于一种关系，我这里耍一个花招，不妨在连上边的同时，标注一下具体说的是什么关系。当然严格定义的图中，边就是边，没什么可以拿来标注的。

让我们回归正题。

3 论计科学生怎么创建一艘船

我们似乎已经解释完成了整体比部分之和多在哪这个问题，那就是部分之间的相互关系，是用图上的边来表示的。但是这个答案不是很令人满意。道理很简单，整体除了具有部分间的相互关系以外，还具有一些它独有的性质和行为。例子可以举出很多，比如“排水量”这个概念无法从木板以及木板间的相互关系里找到，只有组成了一艘船，“排水量”这个概念才有意义；一群水分子并不知道怎么“流动”，除非它们汇聚成宏观的水滴或水流。因此，单单一张图是远远不够的。

 

我们把那些描述一个整体的属性加入到原先那个整体的描述中来。这样原先整体的定义就发生了变化，变成像这样的东西——

class Graph;    //我们之前关于“图”的定义……
struct Thing
{
  Graph components;  //组成整体的部分，就是那张图
  AnyType property1;     //属性1
  AnyType property2;     //属性2 
  //更多属性……
}

不想看“代码”就看这里好了：这里展示了一类东西的定义里面，不止包含我们在第2节里面说的部分图，也包含更多属于这个整体自身，而不是它的某一个部分的内容。这些内容如何定义完全由你说了算。想要一个实数存放排水量？行啊，来一个；想要一个字符串来存放名字？没问题啊；如果想存储这艘船是哪个造船厂建的呢？也行啊。在这方面，它是非常自由的。

这时我们发现，原先最为重要的那个“图”，现在似乎降格成了跟其他属性一样，也仅仅是个属性罢了。话说回来，为什么要把它单独看待呢，难道只是因为几乎所有东西都能拆分成更小的结构，因此这个属性在几乎所有东西中都会出现，逐一定义显得有些白费力气吗？

Mr. K在这里卖个关子，我们先解决另一个看上去同样紧迫的问题。

---

To be continued!

（有耐住性子看到这里的朋友吗？）

你说这些谁听得懂啊