Bean Cart终于完成了……

这几天除了“干某事”之外就是JSP,无论是做自己的还是被人请去共同探讨别人的,在10分钟前终于把自己的搞定了并且传上去了——本来可以很快完成的作业,不过想试一下使用JSTL,就多用了起码一个星期……

这是我有史以来写过的结构最差的Web程序,代码凌乱不堪,没有任何层次可言,Model和Control混在了一起,Control又和View混在了一起。问题在于,即使是购物车这么简单的MVC模型,我也还是没有办法把Model、View和Control彻底分离。

我开始怀疑“JSP文件中不出现Java脚本”的必要性了,当然可能是因为JSTL很强大而我其实不懂得使用JSTL,因为我看到了另外一个人也是用JSTL来做,那代码真是让我Orz啊,看都看不懂……然而又有人说,JSTL也就那么点东西,要用到的时候自然就会了,事实上又是怎样的呢……

又有人要找我共同探讨了……so much fot it.

半癫半疯半痴狂……

搞了这许多天,终于得到一个结论,那就是class文件不能够直接放在/WEB-INF/classes/目录下,而要至少再放进一层文件夹如/WEB-INF/classes/com/xxxxxx.class,为了得出这个结论,我下载了n个源程序来研究了,吐血……

JSP的心头大石总算落地了,还有许多的石头,不过总不至于比这个讨厌吧。

写来玩的

interface 可发射{
//假设某个物体可发射,就应该可以发射炮弹A和炮弹B。
void 发射炮弹A();
void 发射炮弹B();
}

interface 可移动{
//假设某个物体可移动,就应该可以前进和后退。
void 前进();
void 后退();
}

class 加农炮 implements 可发射{
void 发射炮弹A(){//…}
void 发射炮弹B(){//…}
}

class 榴弹炮 implements 可发射{
void 发射炮弹A(){//…}
void 发射炮弹B(){//…}
}

class 柴油动力 implements 可移动{
void 前进(){//…}
void 后退(){//…}
}

class 核动力 implements 可移动{
void 前进(){//…}
void 后退(){//…}
}

class 坦克 implements 可发射, 可移动{
private 可发射 a;
private 可移动 b;

public 坦克(可发射 a, 可移动 b){
this.a = a;
this.b = b;
}
void 发射炮弹A(){this.a.发射炮弹A();}
void 发射炮弹B(){this.a.发射炮弹B();}
void 前进(){this.b.前进();}
void 后退(){this.b.后退();}
}

class 坦克研究所{
public static void main(String args[]){
坦克 a = new 坦克(榴弹炮, 柴油动力);
坦克 b = new 坦克(加农炮, 柴油动力);
坦克 c = new 坦克(榴弹炮, 核动力);
坦克 d = new 坦克(加农炮, 核动力);
}
}

信息集装箱

[JSP]requese中文乱码解决方案

今天上课老师提到jsp中的GET变量传递时中文会变成乱码,这里提供一种解决方案:
String param = new String(request.getParameter(”param”).getBytes(”iso-8859-1″));
另外,强烈推荐用utf-8编码代替gb2312编码,这样可以避免更多的乱码问题,同时便于数据在不同的数据库之间的搬迁。

[PHP]日记本修好了

这两个星期,我把所有的空闲时间都用在修理自己的日记本上面,说白了就是把基于asp的日记本改造成基于php的,然后把IIS删掉,直到刚才总算是完工了。
改造完毕的日记本基本功能已经完备,但是耦合度还不是很好,通过对它的继续改造,将会更加深入地领会跨语言的面向对象思想。

[JAVA]一道国外的JAVA题目

这是一道很简单的Java题目而已,模拟剪子石头布的游戏,但是我感觉到题目的描述很形象地阐释了Java的OO思想。
想起那本Java2实用教程里面的题目,我还是有很大感触的,这里和大家分享一下~~ (more…)

终于把interface啃透了,趁着兴奋写点感受

关键词:接口,多重继承,接口继承,私有接口,构造器与初始化

这种东西不仅要看过和编过,还要知道究竟有什么用,才能够真正啃透。《Thinking in Java》果然是一本很有思想的书,每重看一次就有许多新的感受。

下一个要啃下来的就是内部类、潜套类和所谓的彻底隐藏具体实现。

上Java课的时候看了许多同学演示的他们自己的大程序,感触是,他们都很喜欢在上面放漂亮的图片的,另外,他们认为外观和功能都非常重要,而程序本身的结构往往是一笔带过——这里就不发表自己的看法了,怕板砖。

不知道我像现在这样不停深入研究Java的特性,将来能够有什么用,也许学管理的人都很注重实用性,而我的确不适合学管理吧。但我始终认为,没有对那些特性的理解,还是很难说掌握一门编程语言的;而且对于Java这种注重结构或者模式的语言来说,如果要把它与现实的管理体系结合来开发信息系统,恐怕需要了解很多特性。

diogin@88师兄近来在探讨php下的MVC,我想,要不花点时间去看看php吧,总比困死在asp中要好,而jsp又是那么的遥远……

注:以上并不能算是我的心得体会,充其量只能是我用来安慰自己处于奇特的学习动机中的话语而已。

架构:摒弃MVC

早上的计算机网络上,打开某个记事本,开始考虑陷入困境的日记本大程序的出路。课后回来调整程序架构,成功地实现了除HTML输出之外的所有功能。现记录程序架构,以供自己参考。

三个界面类:
class Controller extends JFrame
class Editor extends JFrame
class Viewer extends JFrame

四个功能类:
class AddDaily extends Editor implements ActionListener, ChangeListener
class EditDaily extends Editor implements ActionListener, ChangeListener
class ViewDaily extends Viewer implements ActionListener, ListSelectionListener
class ControlIt extends Controller implements ActionListener(主控制类)

一个通用最终类:
final class COMMON

一个入口
class Dailybook

在这里有必要介绍一下原有的架构:

三个界面类:
class Controller extends JFrame
class Editor extends JFrame
class Viewer extends JFrame

一个控制类:
class ControlIt

一个入口
class Dailybook

原有的架构的问题在于处理“编辑日记”和“添加日记”的时候,使用了同一个Editor的引用,所以在使用的时候不得不判断是编辑日记还是添加日记,有许多方法都要修改,极之麻烦;同时,所有的控制代码都放在类ControlIt中,使得该类的代码颇为壮观,同时不可避免地产生了无数的内部类,不符合某个美学观点-_-|||。

放弃MVC架构是出于两个考虑:

  1. 事实上不存在类A对类B的实时监听;
  2. 任何两个类之间都不需要共享数据,只有在EditDaily的功能模块中需要传递一个索引值;如果把模式单独作为一个类,那么要解决许多的数据共享问题,在这个程序中并不适合。

新架构的难点在于,当某个功能对象完成任务后,如何通知主控制对象使得主控制对象即使销毁功能对象并返回主控制界面。这个过程类似与对象“自杀”有点类似,于是尝试性地写了一个简单的“自杀”程序:

import javax.swing.JFrame;

class Killer{
void kill(A a){
a.dispose();
System.out.println(”Kill Succeed!”);
}
}

class A extends JFrame{
private Killer killer;
A(Killer k){
this.killer = k;
}
void killSelf(){
killer.kill(this);
}
}

class Entrance{
public static void main(String args[]){
A a = new A(new Killer());
a.killSelf();
}
}

这里模拟Killer是一个生成A的“杀手”对象的类,在创建A的对象的时候,需要同时创建Killer的对象并且传递给A。当调用A的对象的killSelf方法的时候,A会通知自己的杀手把自己杀掉,给“外人”(Entrance)造成了一种“自杀”的“假象”。在这个程序运行正常后,我才开始调整日记本程序的架构,目前已经完成,并且把一些常量抽取到通用类中。

在下午看过师兄们的成果之后,我才发现自己差距甚远……看来要努力往程序里面加一大堆的功能和装饰才好。目前要朝着这个方向努力啊啊……

程序结构

昨天想了很久,最后问了TC聊了一句:

(2006-04-15 21:41:22) .颯沙.
我现在写一个程序,有几个模块,现在要控制它们,你说是把各个模块的控制代码写到各个代码中好,还是新建一个模块专门控制它们好呢?
(2006-04-15 21:41:48) 餃子菜肉包
后者

然后下定了决心。不过,昨天晚上把连数据库的方法找到以后,就去呼呼了……

今天早上起来,打开Java的Project(昨天已经把它改造成Project了,嗯),然后开始把Viewer和Editor中需要添加Action的Component前面的private关键字删掉,然后尝试在Controller里面创建一个Viewer并且为Viewer添加Action,折腾了一阵子后发现,Controller本身也是一个JFrame,所以新建了一个Controlit类来控制3个JFrame:Controller、Viewer、Editor。

整个程序的结构便出来了。其实现在想来,当时采取两种控制方法都有要解决的问题:如果控制代码各自写,就要考虑各模块之间的信息交换问题,例如,Viewer发了一个消息:“我的任务完成了,可以返回Controller了”,那么,还是需要有一个main()来接受这条消息并且关掉Viewer打开Controller,但是main()什么时候捕获消息呢?是监听还是被动等待?这样子问题一下子就复杂了很多。

按照现在的做法就好多了。三个模块都是在Controlit里面定义的,并且模块构造器只是构造界面,而把需要监听Action的控件开放出来接受Controlit的控制,从角度1上看,控制的代码集成到一个类中;从角度2看,Controlit可以随意地监听各模块的Action,从而统筹地作出反应。

这个算不算是设计模式的初级入门基础?