不成功的课

　今天做课，可以准确的说是失败了，讲的是下载与解压。准备的课上得还不如平时的课。学生完全没有达到预想的水平。
　心里非常难过。中午吃不下饭，躲在一边反思。写了大约２０００字的个人反思分析。这是十几年来第二次感到如此明显的失败。刚开始的时候还为自己解释一、二句。最近太忙了，事情太多，还有网管一大堆事情……。但是对于一名教师来说这不是理由。上不好课就是比天塌下来还难受。
　是呀！自己已经相当长一段时间没有狠抓自己的教学了。人总是浮着，没有沉下心来搞教学。忙忙碌碌中好象进步了，但实际上是退步了。
　在即将过去的一年里，我没有注意到这方面的内容。在即将来到的一年里，我一定要努力把这方面的漏洞补上。
　

再败再战！

　前几天，在五１班讲下载与解压，非常不成功。心里沮丧极了，吃不下饭睡不着觉的，有极大的挫折感。几乎认为自己根本不适合当老师了。
　但不服，败后再战！
　今天，重讲。在五3班。今天非常顺利地下来了。原来所有的问题都没有了，扬眉吐气。当教师的自信心找回来了。
　但是，仍然还有疑问：都是五年级为什么会有这么大的差距，一个班艰难晦涩，一个班淋漓痛快。平时为什么没有这知大的感觉？
　其中的问题没有完全想通，仍然是吃不下饭，睡不好觉。

学习的五项首要原理

（1）当学习者介入解决实际问题时，才能够促进学习；
（2）当激活已有知识并将它作为新知识的基础时,才能够促进学习；
（3）当新知识展示给学习者时,才能够促进学习；
（4）当学习者应用新知识时,才能够促进学习；
（5）当新知识与学习者的生活世界融于一体时,才能够促进学习。
－信息技术课、生活算法教学必须遵守的首要教义。

读"促进学习的五项首要原理"
2004年 11月07日
Sunday, November 07, 2004

虽然知道终身学习是现代人的本质属性，但“饱食终日，无所用心”或“群居终日，言不及义”的情景随处可见。自己虽不至此，但也有处于学习低谷、失望高原的时候。日前注意到网上转载的Merrill《首要教学原理》中归纳促进学习的五项首要原理，足可为吾辈指点迷津，它们是：
（1）当学习者介入解决实际问题时，才能够促进学习；
（2）当激活已有知识并将它作为新知识的基础时,才能够促进学习；
（3）当新知识展示给学习者时,才能够促进学习；
（4）当学习者应用新知识时,才能够促进学习；
（5）当新知识与学习者的生活世界融于一体时,才能够促进学习。

这五条想必原来是提醒教师的，比如第一条是要教师为学生设计问题情境。我们虽然已经不是学生，但结合自己情况，仍有很大参考价值。首先，我们要真正解决实际问题。对自学者来说，第一条意味着学习者首先必须是孜孜不倦的实践者——实现现实要求，这会给他以足够的动力。当我们迫切希望解决现实问题的时候，就会体会到“学到用时方恨少”了。又比如第二条，也是提醒教师寻找维果茨基所谓的“最邻近发展区”，为新旧知识设计一个匹配的接口。对自学者来说就是：如果不积极填补新旧知识之间的缺口，你根本就学不下去。再看第三条，自学者不大会有老师主动向你展示新知识，你必须主动寻找，施展你获取信息的能力。而我们周边闭目塞听的人有的是。第四条的要求因强烈动机的存在，一般不成问题。最后，终身学习者在第五条上最具有优势，因为他是主动学习者，他要学的本来就是他生活的内在需要，所以新知识会很快融入他的生活。

知行合一

知行合一 　－－　王阳明
　知难行易　－－　　知易行难
　从修学而言，知识与生活是统一。
　活动是容易的，从活动中抽象出知识难；知道知识是容易的，在生活中贯彻所知是困难的。　－学习生活化。
　我们知道知识是什么，但不太会在生活动中利用知识调控自己的行为。－策略角度

生活算法中的思维（知难行易）

　在生活算法中也强调思维。包括了两个不同的层面：一是知易行难。一是知难行易。
　如果，知的层次比较低。仅仅处于识记、简单体验就能够得到自己是“知易”。
　如果，知的层次比较高。需要在各种不同的活动中总结、抽象出其规律，得到其策略，那么自然就会“知难”。
　在网络上看到了一个编程者的思维体验过程，可以充分地证明“知易”或者“知难”。
　我们准备把信息技术课变成“知易”还是“知难”呢？

改变自己编程中的思维方法(知难行易)
我是从学习Java编程开始接触OOP(面向对象编程)，刚开始使用Java编写程序的时候感觉很别扭，因为我早以习惯用C来编写程序，很欣赏C的简洁性和高效性，喜欢C简练而表达能力丰富的风格，特别忍受不了Java运行起来慢吞吞的速度，相对冗长的代码，而且一个很简单的事情，要写好多类，一个类调用一个类，心里的抵触情绪很强。

我对Java的面向对象的特性琢磨良久，自认为有所领悟，也开始有意识的运用OOP风格来写程序，然而还是经常会觉得不知道应该怎样提炼类，面对一个具体的问题的时候，会觉得脑子里千头万绪的，不知道怎么下手，一不小心，又会回到原来的思路上去。

举个例子，要发广告邮件，广告邮件列表存在数据库里面。倘若用C来写的话，一般会这样思考，先把邮件内容读入，然后连接数据库，循环取邮件地址，调用本机的qmail的sendmail命令发送。

然后考虑用Java来实现，既然是OOP，就不能什么代码都塞到main过程里面，于是就设计了三个类：

一个类是负责读取数据库，取邮件地址，调用qmail的sendmail命令发送；
一个类是读邮件内容，MIME编码成HTML格式的，再加上邮件头；
一个主类负责从命令读参数，处理命令行参数，调用发email的类。

把一件工作按照功能划分为3个模块分别处理，每个类完成一件模块任务。

仔细的分析一下，就会发现这样的设计完全是从程序员实现程序功能的角度来设计的，或者说，设计类的时候，是自低向上的，从机器的角度到现实世界的角度来分析问题的。因此在设计的时候，就已经把程序编程实现的细节都考虑进去了，企图从底层实现程序这样的出发点来达到满足现实世界的软件需求的目标。

这样的分析方法其实是不适用于Java这样面向对象的编程语言，因为，如果改用C语言，封装两个C函数，都会比Java实现起来轻松的多，逻辑上也清楚的多。

我觉得面向对象的精髓在于考虑问题的思路是从现实世界的人类思维习惯出发的，只要领会了这一点，就领会了面向对象的思维方法。

举一个非常简单的例子：假使现在需要写一个网页计数器，客户访问一次页面，网页计数器加1，计数器是这样来访问的

http://hostname/count.cgi?id=xxx

后台有一个数据库表，保存每个id（一个id对应一个被统计访问次数的页面）的计数器当前值，请求页面一次，对应id的计数器的字段加1(这里我们忽略并发更新数据库表，出现的表锁定的问题)。

如果按照一般从程序实现的角度来分析，我们会这样考虑：首先是从HTTPGET请求取到id，然后按照id查数据库表，获得某id对应的访问计数值，然后加1，更新数据库，最后向页面显示访问计数。

现在假设一个没有程序设计经验的人，他会怎样来思考这个问题的呢？他会提出什么样的需求呢？他很可能会这样想：

我需要有一个计数器，这个计数器应该有这样的功能，刷新一次页面，访问量就会加1，另外最好还有一个计数器清0的功能，当然计数器如果有一个可以设为任意值的功能的话，我就可以作弊了。

做为一个没有程序设计经验的人来说，他完全不会想到对数据库应该如何操作，对于HTTP变量该如何传递，他考虑问题的角度就是我有什么需求，我的业务逻辑是什么，软件应该有什么功能。

按照这样的思路(请注意，他的思路其实就是我们平时在生活中习惯的思维方式)，我们知道需要有一个计数器类Counter，有一个必须的和两个可选的方法：

getCount()//取计数器值方法
resetCounter()//计数器清0方法
setCount()//设计数器为相应的值方法

把Counter类完整的定义如下：

publicclassCounter{
publicintgetCount(intid){}
publicvoidresetCounter(intid){}
publicvoidsetCount(intid,intcurrentCount){}
}

解决问题的框架已经有了，来看一下如何使用Counter。在count.cgi里面调用Counter来计数，程序片断如下：

//这里从HTTP环境里面取id值
...
CountermyCounter=newCounter();//获得计数器
intcurrentCount=myCounter.getCount(id);//从计数器中取计数
//这里向客户浏览器输出
...

程序的框架全都写好了，剩下的就是实现Counter类方法里面具体的代码了，此时才去考虑具体的程序语言实现的细节，比如，在getCount()方法里面访问数据库，更新计数值。

从上面的例子中看到，面向对象的思维方法其实就是我们在现实生活中习惯的思维方式，是从人类考虑问题的角度出发，把人类解决问题的思维方式逐步翻译成程序能够理解的思维方式的过程，在这个翻译的过程中，软件也就逐步被设计好了。

在运用面向对象的思维方法进行软件设计的过程中，最容易犯的错误就是开始分析的时候，就想到了程序代码实现的细节，因此封装的类完全是基于程序实现逻辑，而不是基于解决问题的业务逻辑。

学习JDBC编程的经典错误问法是：“我怎样封装对数据库的select操作？”

面向对象的设计是基于解决业务问题的设计，而不是基于具体编程技术的设计。我不会去封装select语句的，我只封装解决问题的业务逻辑，对数据库的读取是在业务逻辑的编码实现阶段才去考虑的问题。

回过头看上面那个发广告邮件的例子，应该如何应用面向对象的思维方法呢？

对于一个邮件来说，有邮件头，邮件体，和邮件地址这三个属性，发送邮件，需要一个发送的方法，另外还需要一个能把所有邮件地址列出来的方法。所以应该如下设计：

类JunkMail

属性：
head
body
address
方法：
sendMail()//发送邮件
listAllMail()//列邮件地址

用Java来表示：

publicclassJunkMail{
privateStringhead;
privateStringbody;
privateStringaddress;
publicJunkMain(){//默认的类构造器
//从外部配置文件读邮件头和邮件体
this.head=...;
this.body=...;
}

publicstaticbooleansendMail(Stringaddress){
//调用qmail，发送email
}

publicstaticCollectionlistAllMail(){
//访问数据库，返回一个邮件地址集合
}
}

当把JunkMail设计好了以后，再调用JunkMail类完成邮件的发送，将是非常轻松的事情。

如果说传统的面向过程的编程是符合机器运行指令的流程的话，那么面向对象的思维方法就是符合现实生活中人类解决问题的思维过程。

在面向对象的软件分析和设计的时候，要提醒自己，不要一上来就去想程序代码的实现，应该抛开具体编程语言的束缚，集中精力分析我们要实现的软件的业务逻辑，分析软件的业务流程，思考应该如何去描述和实现软件的业务。毕竟软件只是一个载体，业务才是我们真正要实现的目标。

但是在设计过程中，心里却往往在担心，如果我完全不去考虑程序代码的实现的话，那么我怎么知道我的设计一定合理呢？我怎么知道我设计的类、接口一定可以实现呢？所以经常可以看到的现象就是：

在设计过程中，虽然知道不能过早考虑代码实现，但是每设计一个类，一个接口，心里都要不知不觉的用自己熟悉的编程语言大概的评估一下，看看能否编出来，因此，一不小心，就会又回到按照程序功能实现的思路进行设计的老路上去了。

举个例子来说明，在做Web程序设计的时候，经常要遇到分页显示数据的情况。比如说需要把系统中所有的用户都列出来这样的功能。假设使用User类来表示用户，增加用户addUser()，删除用户deleteUser()，查询所有用户listUsers()方法。而数据库中有一个user表，一条记录是一个用户的信息。下面考虑一下User类的方法的实现：

addUser()和deleteUser()方法都好实现，就是对数据库增加记录和删除记录。对于listUsers()方法，其实就是对user表的select，取出一个记录集。但是该怎么从listUsers()方法中得到所有用户的列表呢？

一个方法调用的返回值只有一个，没有多个，所以很多情况下采用的办法就是返回值定义为集合类型，比如Vector。这样就可以在listUsers()方法的具体代码实现的时候，从数据库依次取出一个个记录，插入到Vector里面来。在主程序里面，调用listUsers()方法可以返回一个Vector，然后再对Vector遍历操作，就可以得到用户列表了。

publicclassUser{

publicstaticvoidaddUser(...){
//数据库insert一条记录
}

publicstaticvoiddeleteUser(...){
//数据库delete一条记录
}

publicVectorlistUsers(...){
//数据库select结果放到一个集合里面
}
}

这样的设计基本合理，但是仍然有点小问题。因为在设计的时候，就考虑到了用Java的集合类Vector来实现对不定长数据集的存放，因而违反了面向对象设计的一个原则：在设计的时候不应过早的考虑具体程序语言的实现。所以必须用抽象的方法，和具体实现无关的方法来表达业务逻辑。

我们知道，通常对具有集合特征的数据结构进行遍历通常可以使用next和hasNext方法，next实现取下一个用户，hasNext判断是否还有元素。因此我们定义一个接口Iterator，这个接口中定义两个方法next和hasNext：

publicinterfaceIterator{
publicbooleanhasNext(){}
publicObjectnext(){}
}

而User类的listUses方法返回值改为Iterator接口的实现类:

publicclassUser{
...
publicIteratorlistUsers(){
}
...
}

这样就把User类的设计和具体的实现方法分离开了，因为此时任何实现了next()和hasNext()方法的类都可以做为listUsers的返回值，都可以被用来表达“用户列表”，而不仅仅可以使用Vector而已。比如，我可以用ArrayList来表达用户列表，因为ArrayList也实现了Iterator，当然我也可以自己专门写一个类来存放用户列表，只要实现next()和hasNext()方法就行了。

这样在具体的编写代码的时候，程序员具有了最大的灵活性，可以根据具体的情况，采用不同的编程方法来存放用户列表。特别是降低了程序的耦合度，提高了程序的可移植性。对于上面那个JunkMail的listAllMail()方法也同样应该改为接口类型。

然后，在主程序里面就这样来使用User类的listUsers方法：

UsermyUser=newUser();
Iteratoriterator=myUser.listUsers();
while(iterator.hasNext()){
iterator.next();
}

这样就可以完全不用考虑程序代码实现了，从高层次上把功能抽象出来，定义成为接口，同时又可以把系统设计的很合理，完全根据业务的需求来进行设计。

结语

通过上面的几个例子的设计说明，使用面向对象的思维方法，其实是一个把业务逻辑从具体的编程技术当中抽象出来的过程，而这个抽象的过程是自上而下的，非常符合人类的思维习惯，也就是先不考虑问题解决的细节，把问题的最主要的方面抽象成为一个简单的框架，集中精力思考如何解决主要矛盾，然后在解决问题的过程中，再把问题的细节分割成一个一个小问题，再专门去解决细节问题。

因而一旦牢牢的抓住了这一点，你就会发现在软件设计和开发过程中，你自己总是会不知不觉的运用面向对象的思维方法来设计和编写程序，并且程序的设计和开发也变得不再那么枯燥，而一个合理运用面向对象技术进行设计和架构的软件，更是具备了思维的艺术美感。
源引地址：http://dev.csdn.net/develop/article/36/article/44/44786.shtm