架构:摒弃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)造成了一种“自杀”的“假象”。在这个程序运行正常后,我才开始调整日记本程序的架构,目前已经完成,并且把一些常量抽取到通用类中。

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