上士闻道，勤而行之

回头看看，掐指一算，从刚开学写第一次的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中便不知如何解决。于是接下来就是各种不停的查资料或者是向大神求教，最终掌握解决问题的方法，然后继续对付下一个问题。

不得不说，通过这半个学期的实践积累，我对面向对象这个所谓的思想方式似乎有了那么一点的理解。虽然依旧不甚明朗，虽然可能知之甚少，了解的依旧只是皮毛，但是我确实在进步，这是毋庸置疑的。不管大进步还是小进步，在我看来，只要进步了，付出的努力都是值得的！

上士闻道，勤而行之。我虽然不是什么上士，但我依旧在进步的道路上乐此不疲，一路欢快地蹦跶着。