《卡雷尔机器人学Java》笔记

这本书适合初学者，是本不错的编程入门书。虽然是用Java，但是，既是是学其他语言，也可以看下。如果你是有经验的程序员，就不用浪费时间了。

关于面向对象

这种把程序分割成小单元的谋划，是编程风格的重要组成部分，而现代语言例如 Java,强调了不同的编程模式，叫面向对象模式。在面向对象模式下，程序员的注意力被从关注特定操作的过程单元中转移出来，侧重到：为被称为对象的单元，抽象建模的行为上。

面向对象模式的主要优势之一是，它鼓励程序员认识到一个对象的状态和其行为的基本关系。一个对象的状态，涉及到一组和该对象相关，并可能随时间而改变的特性。

在面向对象编程的语言中，触发指定对象的行为的通用词叫消息--message（虽然从卡雷尔的上下文上看，命令--command 这个词可能更让人明白点）。

一个对象和一个类之间概念的区分是很有必要的。最容易理解这种分别的方法是把类认为是一些对象（共同）的模式或模板，这些对象都有一个共同的行为和状态属性的集合。（注：1）

关于面向对象，其实，并没有太多选择。主流的几种开发语言都是面向对象的。作为初学者，明白什么是面向对象就好了，一些关键的感念，不要搞混了就好。对这个概念的理解会在之后的实践中加深的。

关于注释
在一个简单的程序里，广泛的注释似乎是愚蠢的，因为程序的效果是显而易见的，但是，在设计更大，更复杂的程序时，注释是一种非常有意义的记录。

注释是让所有程序员，特别是涉及到项目管理的人员头痛的问题。注释总是在需要的时候显得不足，而在不需要的时候显得多余。人都是懒得的，谁都不愿意写大量的注释。在看自己的程序的时候还好，当需要理解别人的程序的时候，注释总是不够。当你面对一个巨大的项目，公司自成立至今所有人都在里面修改过，这个时候你恨不得每行都有注释。
合理的程序设计可以减轻对注释的需要，但是，在不停赶工和巨大的进度压力下，又有多少是合理的程序设计呢？我能想到的最好的解决办法还是通过规范，让大家写出相同或者近似相同的程序来，这样应该会好点。总之，注释是一个令人既爱又恨的东西。

关于功能划分

尽可能的保持定义私有化，总体来说是一个好的编程习惯。在你有机会为大项目工作之前，这么做的理由，你很难体会到。但是，基础的思想是，这些类应该试着尽可能多的封装信息，这意味着这些类不仅可以聚集在一起工作，而且尽可能的限制（这些类之间互相的）访问信息。大型程序在它们包含的项目的细节数量上很快变得非常复杂。如果一个类被设计的很好，它将通过隐藏尽可能多的额外信息来寻求降低系统的复杂性。这种属性被称为信息隐藏，是面向对象哲学的一块基石。

一般来说，决定如何分解一个程序不容易。选择一个适当的分解，将变成编程中比较困难的一个方面。但是，你能在一定程度上依赖以下原则：
1.每一个子问题应该执行一个在概念上是很简单的任务。一个子问题的解决方案也许需要许多条命令，也许在内部操作条件方面相当复杂。即便如此，它最终应该完成一些在概念上容易描述的任务。如果你给出的动作名字能成功的概括出一个合理的任务，是一个好迹象。如果你可以通过一个简单的描述性名称，准确的定义（这个动作）它的作用，你可能已经选择了一个很好的分解方案。另一方面，如果你最终使用了像 approachAndFillPothole 这样的复杂名称，这个分解方案不像有前途。
2.每个子问题应该执行尽可能具有通用性的任务，这样，这个（子问题）就可以在几个不同的场景下调用。如果一个分解方案的结果只能在一个特定的场景中使用，而手上的另一个在几个不同的相关场景中都能工作的同样好，你应该选择更通用的那个。

把起初的一个问题，分解为许多要解决的小问题，这叫自上而下设计或逐步求精，它是出自软件工程的，最重要的方法论发展。你把整个问题分解成小块，然后解决每一块，如果有必要，那些分解的块还需要进一步的分解。

从我的实践来看，宏观上的功能划分通常不会有太多问题，但是到了细节上，比如是用一个方法还是用几个方法实现或者构造新的类，这个时候，通常会疏忽。很多时候，在拿到任务以后，通常没有更深的思考就冲着完成功能去了。比较悲惨的结果就是写了一个巨大无比的方法，几百行的代码，若干循环分支嵌套，纵然是用visio画的图也是密密麻麻，让人眼花缭乱。这时候再写什么样的注释，别人，甚至自己都无法完全看懂。有时候会通过一些硬性规定来避免这样的情况，比如，每个方法或者函数不能超过150行之类的。这样会有一些效果，但是，更多的时候，应该思考下，有没有更好的方法。