小A：“师兄，用任意一种面向对象语言实现，就是要用面向对象的编程方法去实现，对吗？”
大B：“一般编程初学者都会遇到这样的问题，碰到问题就直觉地用计算机能够理解的逻辑来描述和表达待解决的问题及具体的求解过程。其实这是用计算机的方式去考虑它，就好比计算器这个程序，先输入两个数和运算符号，再根据运算符号判断选择如何运算，得出结果。这样是对的。但这样的想法却使得程序只为满足实现当前的需求，而程序就不容易维护，不容易扩展，也更不容易复用。也就达不到高质量代码的要求了。”
小A：“师兄，你这样一讲我又不懂了，那怎么程序才能容易维护，容易扩展，也容易复用哩？”
大B：“我再跟你讲细点吧！顺便也举些例子，理解一点。发广告邮件，广告邮件列表存在数据库里面。倘若用C来写的话，一般会这样思考，先把邮件内容读入，然后连接数据库，循环取邮件地址，调用本机的qmail的sendmail命令发送。然后考虑用Java来实现，既然是OOP，就不能什么代码都塞到main过程里面，于是就设计了三个类：一个类是负责读取数据库，取邮件地址，调用qmail的sendmail命令发送；一个类是读邮件内容，MIME编码成HTML格式的，再加上邮件头；一个主类负责从命令读参数，处理命令行参数，调用发email的类。把一件工作按照功能划分为3个模块分别处理，每个类完成一件模块任务。仔细的分析一下，你就会发现这样的设计完全是从程序员实现程序功能的角度来设计的，或者说，设计类的时候，是自底向上的，从机器的角度到现实世界的角度来分析问题的。因此在设计的时候，就已经把程序编程实现的细节都考虑进去了，企图从底层实现程序这样的出发点来达到满足现实世界的软件需求的目标。这样的分析方法其实是不适用于Java这样面向对象的编程语言。”
小A：“为什么？”
大B：“因为，如果改用C语言，封装两个C函数，都会比Java实现起来轻松得多，逻辑上也清楚得多。”
小A：“我倒觉得面向对象的精髓在于考虑问题的思路是从现实世界的人类思维习惯出发的，只要领会了这一点，就领会了面向对象的思维方法。”
大B：“这样吧，我再举一个非常简单的例子：假使现在需要写一个网页计数器，客户访问一次页面，网页计数器加1，计数器是这样来访问的如：http：//hostname/count。cgi？id=xxx 后台有一个数据库表，保存每个id（一个id对应一个被统计访问次数的页面）的计数器当前值，请求页面一次，对应id的计数器的字段加1（这里我们忽略并发更新数据库表，出现的表锁定的问题）。”
大B：如果按照一般从程序实现的角度来分析，我们会这样考虑：首先是从HTTP GET请求取到id，然后按照id查数据库表，获得某id对应的访问计数值，然后加1，更新数据库，最后向页面显示访问计数。
小A：“现在假设一个没有程序设计经验的人，要怎样来思考这个问题的呢？会提出什么样的需求呢？”
大B：“你很可能会这样想：我需要有一个计数器，这个计数器应该有这样的功能，刷新一次页面，访问量就会加1，另外最好还有一个计数器清0的功能，当然计数器如果有一个可以设为任意值的功能的话，我就可以作弊了。做为一个没有程序设计经验的人来说，他完全不会想到对数据库应该如何操作，对于HTTP变量该如何传递，他考虑问题的角度就是我有什么需求，我的业务逻辑是什么，软件应该有什么功能。”
按照这样的思路需要有一个计数器类Counter，有一个必须的和两个可选的方法：
getCount（）//取计数器值方法
resetCounter（）//计数器清0方法
setCount（）//设计数器为相应的值方法
把Counter类完整的定义如下：
public class Counter{
public int getCount（int id）{}
public void resetCounter（int id）{}
public void setCount（int id，int currentCount）{}
}
解决问题的框架已经有了，来看一下如何使用Counter。在count。cgi里面调用Counter来计数，程序片断如下：
//这里从HTTP环境里面取id值
……
Counter myCounter=new Counter（）；//获得计数器
int currentCount=myCounter。getCount（id）；//从计数器中取计数
//这里向客户浏览器输出
……
程序的框架全都写好了，剩下的就是实现Counter类方法里面具体的代码了，此时才去考虑具体的程序语言实现的细节。
面向对象的思维方法其实就是我们在现实生活中习惯的思维方式，是从人类考虑问题的角度出发，把人类解决问题的思维方式逐步翻译成程序能够理解的思维方式的过程，在这个翻译的过程中，软件也就逐步被设计好了。
大B：“在运用面向对象的思维方法进行软件设计的过程中，最容易犯的错误就是开始分析的时候，就想到了程序代码实现的细节，因此封装的类完全是基于程序实现逻辑，而不是基于解决问题的业务逻辑。”
