面向对象设计原则——谁拥有数据，谁就对外提供操作这些数据的方法。
    首先，我很认同这一点，彻底让我理解这点的是张老师举的列车司机刹车和人用手关门的例子，
    刹车时，司机并没有具体操作怎么去刹车，而是由列车自己去完成的，人只是踩刹车给列车一个信号，或者说一个功能实现的请求，真正完成刹车的是拥有刹车系统的列车，只是列车是按照我们司机的指示操作刹车的而已；

人用手关门，人自己没法关门的，是门自己通过自身旋转关上的，人只是给了操作信号，门接收到了这个信号，在人外力的协助下转动自己完成关门动作的。
     这两个例子很好让人理解面向对象是的这个设计原则。但老师提到的在黑板上画圆的例子我就要提点不同意见了。
     人在黑板上画圆这个例子却不好分清谁提供了完成画圆的方法，是圆么？个人认为不是，画圆的参数，直径和位置等等信息可是在人脑海中的，不是圆拥有的，完成画圆这个动作可是完完全全是由人完成的，更何况圆只是最后的结果，圆都没有出来呢，怎么提供操作方法啊？
     同样的，售票员统计收获小票的金额这个例子，也是让人老师解释的总有些别扭的。


     我认为，对于人在黑板上画圆这个例子，可以将画圆的工具当作圆心和半径数据的拥有者，让其提供对数据的操作方法，这里当然就是粉笔（如果想精准画圆则可以考虑用圆规)了，而没有粉笔我们也没法画出圆让其显示出来的。另外，我们将一个方法交给一个没有成形的事物--未画出来的圆，也不利于我们程序的更新升级，检查错误呀，圆如果作为模式封装了方法和数据，对外提供操作，我们还不好改变圆心和半径的数据，圆先的自毁旧的自己，再创造新的自己，那样，效率能高么？麻烦能少么？

列车司机刹车的例子，没有将数据方法封装到“刹车”这件事上，而是封装给车;人关门没有将数据方法封装在“关门”这件事上，而是封装给了门；
    所以，我想对这个原则补充一点，“谁拥有数据，谁就对外提供操作这些数据的方法”，但是要尽量回避将数据和方法封装到我们的目标事物上。
    一点粗略看法，希望能和大家讨论讨论。

好的，学习学习。加油呀

手机党表示看完很费劲,尤其是每段都设置了不同的字体:-(
首先,我不同意楼主的观点,没有粉笔没有人一样可以用别的东西(大自然怎么样,很奇妙的造物者)画圆等.可能"圆画自己"是挺怪异的,那火车自己刹车就不怪异了么?
我觉得面向对象的思想是把任何"事物"(哪怕这个对象是个动作)都当成静态事物看待.也可以这个对象是个问题,我们要做的是这个对象有什么用,而不是去想为什么会有这个对象.可能不太恰当.
用电脑来说,面向过程:要实现内部的数据处理;面向对象:电脑能干什么.
至于鼠标键盘这些东西,都是属于电脑的,虽然这些东西是你买的…
个人理解,还望指正

王松朝，很认同你提到的这点“面向对象的思想是把任何"事物"(哪怕这个对象是个动作)都当成静态事物看待”，我也不再纠结这个事物存在不存在，这个动作或是目标有没有完成了。
    像你提到的，把画圆这个动作看成一个静态事物，圆看成另一个事物，列车看成一个事物，刹车这个动作或说事件看成一个静态事物。
    现在是在考虑一个效率问题了。圆自己画自己，跟列车自己刹车还是有很大区别的：列车刹车是一个重复操作（且多的时候还会是一个稳定且经过检验的），圆自己画自己的话那就是一个更新操作了。试想一下，我们测试或是验证下列车刹车效果好不好，不一定非得刹车试试，我们看看零部件是否完好，连接是否正常不就行了么。但是圆画的好不好，我们得等圆出来后才能调整。如果将画圆方法教给圆规之类的工具，我们只需校正工具的误差即可。
    我就想彻底搞明白，数据和方法封装给哪个静态事物最适宜我们解决问题。由此看，最好还是不要将数据和方法封装给未实现的事物上或是还不存在的事物上。
    这么看，你觉得怎么样

你可以认为每个图形都有一个draw（）方法，圆也有，而人只要调用这个方法，把圆心，半径，写进去就行了。
这样就可以理解为是圆拥有画圆方法。就像火车刹车一样，他自己有个方法叫刹车。一调用就停了。虽然还没有特定的圆对象，但是圆的类确实是存在的。

张，你的理解我不反对，画圆把方法教给圆我也能理解，但我觉得方法教给别的事物会更好一些，也就是效率问题了，这个问题会在以后开发中，自己多经历我觉得才能显示出来，现在我这方面的经验少，只是理论层次的推测，以后再验证了。