今天在学习模块设计的时候碰到了一个问题，那就是耦合度和内聚度的问题，以及在一个程序里面看到了console类，所以想把自己的一点小小的理解和收获写在这里。

我们在设计一个面向对象的实例化程序的时候，就要分成很多的模块来处理，因为一个面向对象的程序是要实现很多种不同的功能的，所以我们再划分模块的时候是要考虑这个耦合度的问题的。我在百度上搜索之后的除了耦合度的定义：那就是各个模块之间的联系的紧密性，甚至还可以理解成依赖性。而各个模块之间的耦合度越高，则这个程序的可维护性以及修改性就越低。

这句话该怎么理解呢，我举个简单点的例子吧。比方说朱元璋和陈友谅正在打仗，而此时朱元璋的部队分工很不明确，他手下有三个集团军，分别由徐达、汤和以及常遇春率领，但是他们还在另外的两支队伍里面担任了职务，于是三支队伍的关系变得很亲密，但是当三个人之间有矛盾的时候，那这三支队伍该怎么办？听谁的号令？这就变成了一个很棘手的问题。同样的，三个集团军就可以理解成一个达程序的三个模块，分别要实现不同的功能，但是当联系太大了之后，一旦某个模块出现了问题，那么整个程序就会出现崩溃的情况。所以在设计划分模块的时候我们一定要坚定的将耦合度降到最低，但是模块之间不能没有耦合度，因为这样子也是不现实的，虽然模块执行的是不同的功能，但是还是为了一个主子在做事，所以还是要有一定的耦合度的。

我们再说说刚才提到的内聚度的问题。

所谓内聚度并不是跟耦合度意义相反的名词。两个人虽然总是一同出现，但是两个名词的官阶是不一样的。

如果我们把耦合度比喻成一个集团军的政委或者是司令员，那么内聚度顶多也只能是军长之类的。因为内聚度指的是模块内部各个小程序之间的关系。大家便可以想像一下，一个集团军在作战的时候打击的目标是一样的，所分得的任务也是一起执行的，那么这里面的所有的师级单位该怎么办呢？肯定是团结一致，拧成一股绳，这样子才能发挥最大的战斗力。所以设计的时候要求的是模块下面的小程序的内聚度必须要很高，因为只有这样子才能发挥最大的功效，让程序能够执行到最高的效率。

总结一下，就是设计程序的时候的原则：高内聚低耦合。【很重要的一条原则！】

接下来再来说说console类的问题。我是在一个计算器程序中看到这个类名的。当时就觉得我根本就不认识他，但是估计他很有名，所以就非常想认识。于是到处打听，在百度上找到了关于这位仁兄的资料，也让大家看看：

        console.write：表示直接向控制台写入字符，不进行换行；

       console.writeline：表示直接向控制台写入字符之后进行换行。

       console.read：表示直接从控制台读取数据，也是不换行的；

      console.readline：表示直接从控制台读取数据，但是会换行。

      console.readkey：获取用户按下的下一个字符或者是功能键。按下的键显示在控制台窗口中。

上面这些呢都是console这位类兄的用法。已经能够使我大开眼界了，但是还有两个客人时不得不介绍出场的，这两位就是console的左膀右臂啊，因为他们是console类的方法。而我们知道方法的调用的时候要么就是实例化该类的对象要么就是直接访问，还有一种更加刺激的方式，就是老子不能实例化，那就让儿子来把老子的对象实例化了，再去访问。这三种我们分别给去了别名，以此为：普通类、静态类、抽象类。我们还是回来继续说说console的两个方法：

      console.Beep 通过控制台扬声器播报提示音；

     console.clear 清除控制台缓冲区和相应的控制台窗口的显示信息。

关于上面这个beep，我只知道他的英文意思是警笛声，不过用在这里方法函数，表示响铃播报，还是蛮形象的。在这里还想多一句嘴，beep的父亲可是鼎鼎大名的，他就是BEEP：传说中的blocks extensible exchange protocol，中文名字叫做：块可拓展交换协议。支持的功能还是很多的，像：分帧啊，异步请求啊，报错啊等等，虽然我还没有机会目睹他老人家的尊容，但是我已经进来了，我想我能够在某一天认真的去拜会拜会他老人家的。

    写了这么多，希望的是在尽可能的一种很轻松的氛围中说出自己的一点小小的收获。程序这个江湖太大，前面已经有很多的高手出现了，但是老苏不是有句话说的很好吗：“大江东去，浪淘尽，千古风流人物”。是啊，每一代都会有风流人物出现，我们都有能力去做，重要的还是那句话，要有恒心有毅力啊！