回头看看，掐指一算，从刚开学写第一次的OO作业开始至今，已经半个学期了。
这半个学期以来，OO作业已经写了五六次了，每一次好像在拿到作业之后心里面只有满满的不想开始写......而且每一次写的时候好像都是那么的困难，毫无头绪，扎耳挠腮，通宵达旦，直至最后到了deadline，大部分情况下都惊险飘过，当然也有一次最终还是功败垂成，至今想起来都感觉太可惜。
记得刚开学的时候，我自己对写Java工程（就当咱的OO作业写的是工程吧）毫无概念。第一次作业要求处理多项式的运算，需要C代码和Java代码各一份，鉴于我当时只对Java存在理论上的了解而几乎从来没有进行过一些代码的训练，所以在我的头脑里实在是没有任何思路。于是，最终我傻傻地将C语言的代码原封不动地复制到了Eclipse里面，然后将相应的C语言语法修改为Java的语法。本来我觉得第一次就先这么先水水的过去吧，交完作业之后就开始好好学习Java工程的写法，结果没想到将C语言语法改装成Java的语法并不是我所想象的那么简单！整个过程真的是一个bug未平，一个bug又起，弄得我叫苦不迭。可是既然刚开始选择了这样做，而且自身本来就hold不住Java工程，干脆硬着头皮一条道走到黑！最终，当我终于筋疲力尽地把代码上交的时候，我只能暗暗发誓----这一定是我唯一的一次将C语言的代码直接不加分析整个换装成Java语言，以后我再也不会这么干了！
呵呵，真是好傻好low的行为！现在想想真是笑死人了。
从上面的经历至少可以看出，我写OO的经历不仅不是一帆风顺，简直就是筚路蓝缕，一点点儿杀出血路来的。而在这一条自己一步一步踩实的道路上，我的确付出了很多，辛苦了很多，但是一直到现在，我觉得我得到了更多！
在一开始写电梯的时候，我就遇到了一个困惑--------对电梯的指令需要进入一个队列，而之后要多次用到这个队列，如果是c语言，毫无疑问我会把这个队列设置为全局的变量，那么在Java存在多个类的情况下，我到底应该怎么做呢？
一、使用static阶段
首先，我想到的依然是类似于c语言中的全局。即把队列变成static类型，这样的话大家都可以调用这个队列了，问题貌似是迎刃而解了。然而，这种行为虽然可以达到目的，但实际上是要尽量避免static变量的。因为static是在容器加载的时候就已经加载到内存中，程序运行期间会一直占用内存，不被释放，这对程序的运行显然是不利的。而且，后来慢慢了解到static方法不能被子类继承，也就不能实现重写的多态。除此之外，如果static是写在单例中，高并发访问是会出问题的，这时候就要设置线程等待了。
显然，盲目地将指令队列设置成"全局”的变量是不太合适的。
二、使用方法封装阶段
因此，后来经过我的各种搜索查找，终于找到了另外一种写法--------
比如类Queue新建了一个队列queue，在类A中我想用到这个队列queue，那么我可以这么写：
class A{
private Queue queue = null;
A(Queue queue){
this.queue = queue;
}
}
即，在类A中新建一个Queue类型的引用queue，然后在构造A的对象的时候，将Queue类型的queue传参，就可以实现对同一个指令队列的调用了。
当然，如果不想在构造对象的时候就这么传参，也可以写成这样：
class A{
private Queue queue = null;
private setQueue(Queue queue){
This.queue = queue;
}
}
即通过普通的setQueue函数来调用，其实质跟在构造函数中调用是一样的。
原本到此，我觉得问题确实已经算是得到完美解决了，没想到同寝室的呦呦鹿鸣又让我见识到了另外一种方法，准确的说是一种设计模式--------单例模式。
三、使用单例模式阶段
单例模式，仅仅从名字上就可以看出来，是针对于只产生一个实例对象的设计模式。其整体思路是这样的：
1.为了避免其他程序过多建立该类对象，先禁止其他程序建立该类对象；
2.但是又需要让其他类可以访问到该类对象，所以需要在本类中，自定义一个对象；
3.为了方便其他类对自定义对象的访问，可以对外提供一些访问方式。
整体思路就是这样，还算是比较简单，我们可以看看单例设计模式的代码：
public class GlobFlag {
private int timerFlag = 1;
private GlobFlag(){}
private static GlobFlag instance = new GlobFlag();
public static GlobFlag getInstance(){
return instance;
}
public int getTimerFlag() {
return timerFlag;
}
public void setTimerFlag(int timerFlag) {
this.timerFlag = timerFlag;
}
}
为了体现单例模式的设计思路，我们同样需要做到以下三步：
1.将构造函数私有化；
2.在类中创建一个本类对象；
3.提供一个方法可以获取到该对象。
回归到上面的代码，我们就可以看到首先我们将GlobFlag类的构造函数权限设置为private，这样其他类就不能实例化出GlobFlag类型的对象，第一步就完成了。接下来第二步，还要造一个对象出来，让大家都能用，所以我们private static GlobFlag instance = new GlobFlag()，在本类中实例化了一个对象instance。而我们将其权限设置为了private，所以就需要有一个getInstance方法来得到这个对象，这就是最后一步。由于其他类不可能建立GlobFlag类型的对象，所以为了能够调用这个方法，就只能将其设置为static类型的，这样就可以通过类名直接调用了。当然，涉及到这个静态方法的对象instance自然也要是静态的。这样的话，就可以在其他类中安全的调用和修改"全区变量”timerFlag了：
GlobFlag.getInstance().getTimerFlag();
GlobFlag.getInstance().setTimerFlag(3);
以上的单例模式，便是对我的代码中的"唯一的Queue类型队列queue”这一要求的完美实现。
更进一步，单例模式还有"饿汉式”和"懒汉式”，而且涉及到"懒汉式”的话，在进行多线程的调度的时候，还要考虑同步的问题，将其用synchronized锁住，才有可能不会产生线程同步和安全问题。不过这些都是后话了。
以上便是我这半个学期以来写OO作业的一个缩影：由于不熟练，所以会碰到各种各样的问题，这些问题在c语言中我可能还有些概念，可是到了Java中便不知如何解决。于是接下来就是各种不停的查资料或者是向大神求教，最终掌握解决问题的方法，然后继续对付下一个问题。
不得不说，通过这半个学期的实践积累，我对面向对象这个所谓的思想方式似乎有了那么一点的理解。虽然依旧不甚明朗，虽然可能知之甚少，了解的依旧只是皮毛，但是我确实在进步，这是毋庸置疑的。不管大进步还是小进步，在我看来，只要进步了，付出的努力都是值得的！
上士闻道，勤而行之。我虽然不是什么上士，但我依旧在进步的道路上乐此不疲，一路欢快地蹦跶着。