在面向对象设计方面我只是一只小小的菜鸟，因此没有什么勇气去谈看法或理解，更不能全释其理论和含义，本文中我只是从一个程序开发人员的角度来谈谈我眼中的面向对象设计。
      我首次接触面向对象概念之前其实已经旧闻大名，当时常听高手们所谓的眼中只有对象，多想What，少想How之类的，但是丝毫没有理解是怎么回事，但是当时确实有一些问题经常困扰自己，相信这些问题大家也会碰到，举三个例子吧：1、经常不能确定属性、方法、类的取名，随着程序的修改而经常修改；2、常常把属性或方法从一个类中转移到另一个类中，但是是否合理自己总说不清楚；3、程序写的越大思路越混乱，常常不知道该怎么继续下去。我是从C语言开始写程序的，现在啥语言都用，上述问题中的属性在C中并不存在，通常叫变量，方法叫函数，呵呵，先不管这么多了，现在这些概念在我脑子里更加“模糊”了。
      我是因为倍受这些困扰才开始学习面向对象设计的，因此在我眼里面向对象设计的学习更像是学习“把合适的代码写在合适的地方”，在高手们看来可能很奇怪，但是我的确就是这么开始的，需要说明的是引号中的那句话更代包我在面向对象的设计和编码方面的理解，这句话也是我现在同朋友们讨论问题时经常会用到的。
      看法一：当我无法确定类、属性、方法的取名时，我就觉得应该是类的抽取或对其对应的实体（为何存在的理解）存在问题。理由好像比较简单，如果我们能确定一个类是桌子，那么它就应该有X条腿，如果它是鸟，那么它就应该有翅膀一样，这些是无庸置疑的。哦，最早我就是通过这种方法确定规则的，但是随后又发现了问题，有时候我压根就搞不清楚它是不是一个桌子，其实这些问题通常不会存在，因为我们做设计的时候总是有一些依据，无论需求分析或概要设计是否清楚，那么通常总能够推断出一些想法/建议来，实在不能确定的，我宁愿暂时将之束之高阁，也绝不能随意决定它是什么，有百害而无一利。
      看法二：当两个类的定义都确定了，那么这两个类的关系也应该是确定的，问题只是实现这种关系的方法不同而已。这种不同并不是由设计工具或编程语言决定的，而是由做设计或编码的人（的想法/理解）决定的。有时候，一个方法该写在这个类还是那个类中并不重要，重要的是不要存在重复的代码，重复代码指不是指相同的方法名，而是指实现相同功能的代码重复出现。呵呵，太拗口了，举个例子吧，有一个用户类User，一个角色类Role，用户类中有一个方法可以让用户扮演一个角色ActAs(Role r)，那么是否可以在Role中增加一个方法AddUser(User u)，加不加都可以，不同的编程习惯和思维习惯的人考虑这类问题的方式不一样，关键是怎么来避免重复代码，如下：User.ActAs(Role r){ /*实现方式略*/ }，Role.AddUser(User u){u.ActAs(this);}，看起来很简单吧，这也是设计和编码不完全相同的理由之一，呵呵，其实类似的例子非常多，仔细读读自己的代码，看看会不会有类似的问题。其实造成这个问题的原因并不是程序写的好不好，即使代码重构也无法解决这些问题，我的理解写程序的人压根不清楚自己写的类到底是什么，为什么会有这些类，因此自然也就不知道这些类该做什么，会不会有其它类和它有类似的职责，导致重复代码的出现。
      看法三：这个理解其实是针对问题三的，当然造成问题三的原因还有其它问题，比如需求说明和需求分析的不明确或不完成等，但是从前两个理解中不难看出，我们在写程序时可能因为有太多的困扰（不知道在写什么、不知道以前有没有写过类似的东西）导致我们无法集中精力写完当前的类或方法。应该说我无法告诉大家如何解决这个问题，这里我只是谈一下自己的看法，当我们对一个项目中的程序感到迷惑或纳闷时，并不是因为这里面的属性、方法、类太多，而是因为我们无法理解这些属性、方法、类到底是什么，你能想象ActAs是一个为角色增加权限的方法吗，或者Role其实是用户类吗？这样混乱的名字（其实代表的是设计者或开发者的思路）不读细节代码是根本无法读懂的，刚才举的例子比较极端，实际情况下哪怕只差一个字母，也足以显示出设计者或开发者的思路是否清晰，混乱的思路怎么可能把设计/程序做大，这样最后导致的只有设计/编码的崩溃。
      以上是一个小小菜鸟发表的不知天高地厚的看法，各位高手觉得不合适的尽管批评，也非常欢迎大家通我讨论有关于面向对象分析设计或数据库设计方面的问题。

《面向对象启示录》是一本好书，作者的功力很深厚，看这本书的时候有一种志同道合的感觉，作者把面向对象上升为一种哲学来看待，非常欣赏。我觉得作者想表达一种想法：“面向对象设计并不是靠对象来构建设计，而是通过这种方法得到较好的设计”。