每件是都需要过程，说要成为专家，至少需要10年艰苦的努力。面向对象设计也是一样的，需要在实践中慢慢摸索，慢慢体会。
不要以为大师们的UML图是一下子画出来的，也是经过无数次修改而得来的。不要以为把大师们的UML图搬过来就可以用，也许它不能解决你的问题。
要做好的软件设计必须要对业务精通。第一，是软件本身，潘爱民老师说：” 没有足够的代码量，很多程序设计的概念是很难体会到的”。第二，是实际的业务，如果没有明确了解业务，那设计也是不存在的，即使做出来了，也是空洞的。
大师还是很少的，那，不是大师怎么办呢？像潘老师说得那样，从日常的编码过程中，慢慢提高。理论要联系实际，当你在实践中真正看到它的效果的时候，它才是属于你的。
看一下，本站短信模块代的码重构过程，希望能通过这个例子说明我的意图。
短信模块的目的：为本站会员提供,在站内及时交流的工具,短信模块有以下功能，
-发送短信
-读短信
-删除
-查看短信邮箱
没有重构前的代码结构如下，
查看代码
这段代码,功能上是没有问题的，但类中方法比较多，看起来不方便，最苦恼的是,每当要添加新邮箱时，需要在每个CASE里加一条语句，来判断新邮箱该怎样处理。这应该就是大师所提及的code smell吧。
重构的思路是这样的，
-定义一个邮箱父类，然后让新邮箱类、已读邮箱类、已发邮箱类、系统邮箱类继承邮箱父类。
-定义一个函数负责生成具体的邮箱类,这样，在添加新邮箱时,只要继承父类，在生成函数中，加入if语句就可以了。
-定义一个邮局类，负责发送短信和生成用户所需要的邮箱。原来的类中含有多种功能，思路不明确。
查看代码
重构之后的代码，思路明确，维护和扩展都很方便了。
在这个例子里我学到了，明确了，
-Factory Method工厂模式
-Open-Closed Principle 开-关闭 原则
-Single Responsibility Principle 单一职责原则
面向对象的世界里，像原则、设计模等理论的东西很多，这些原则和设计模式是起指导作用的，而不是让我们把它硬生生地放到设计里。其实在上面的例子里，如果只有两个邮箱，那，不重构也是可以的，因为没有必要。
上面的例子更像是敏捷所提倡的方法，先编码，后重构。要是没有敏捷方法的出现，谁会赞同上面的方法是正确的呢？所以，做自己的面向对象，让别人说去吧。