离弦之Ray

 

Decorator Pattern其实早就接触过了，从java的输入语句中可见一斑InputStream in = new BufferedInputStream(new FileInputStream(“test.txt”)); 其中BufferedInputStream 和FileInputStream 都是InputStream的子类，通过包含关系，让外围的类包含内部那个类的功能及数据，说的形象一点，就是在内部那个类外面加了一层装饰。这也是装饰模型最核心的概念。

Factory Pattern

书中举了匹萨店的例子，一开始的类，将制作不同类型匹萨的方法都包含在里面，整个类显得很冗余。顺着正常的思路，将制作匹萨的方法从这个类里面剥离出去单独形成一个类，这个类就像生产对象的工厂，只要你告诉它该生产的产品的型号，它就生产对应的对象再发送给客户。

按照书中的例子，如果匹萨店开在同一个城市以内，匹萨的风味多样，那么上述的模式很好地实现了上面的功能。但如果是连锁店，每个地方的风味不同呢？……

是的，每个地方的风味不同，但同一个地方不同匹萨的种类却相当有限。也就是说可以有一个匹萨店父类，然后各地的分店是这个父类的子类。而其中最重要的制作匹萨的方法在父类中被声明为虚函数，由各个具体的子类来实现。这样“工厂”又被搬回具体的类中间。

具体如何使用，我个人觉得是要看情况的。上面两个是工厂模式的两种表现形式。

    对于后一种模式，里面用到的对象，比如例子中匹萨的原材料，同样可以用工厂模式来实现，这样程序的结构就相当灵活了。

 

       这是《Head First Design Pattern》里面介绍的第二个Pattern，叫做Observer Pattern，其核心概念就是一种一对多的关系。

其中的“一”，类似于定报纸系统的发送方，而“多”就是订阅方。当有新的“报纸”时，发送方将最新的报纸送达订阅方手中。发送方维护着一个订阅方的列表。

文中通过一个气象站的例子来解说这个模式。WeatherData实现Subject接口，里面包括所要传送的private 数据，还有注册Observer和去除Observer的方法。当数据有所更新时调用measurementChanged方法，这个方法再调用notifyObservers方法。

而在Observer那端，有一个subject对象的私有数据，通过构造函数将要注册的Subject作为参数来对它进行初始化，以此建立Observer和Subject的联系。

最后还介绍了java那建的Observer模式。通过继承Observable来成为Subject，通过实现Observer接口来成为Observer。但其有一定弊病，因为java不支持多继承，这就限制了使用这个模式的灵活性。所以我觉得以后如果真的用到Observer模式还是自己编程比较好。

    好久没进入linux系统了，今天心血来潮，一进去，想玩一下更新系统。然后就从想用那个图形界面的更新程序。可惜阿，点上去都说有一个程序正在读取软件信息。于是重启，但还是如此。
    突然报出有240个软件包可以更新，原来是自动更新在作怪。

    然后就顺理成章地点吧，还挺顺利，它就开始更新了。但更新着就在那不动了，奇慢无比。

    在老婆的指导下，我上网查了一下yum的用法。

    打开终端。
    首先使用yum list来查看更新列表，刷的一下出来好多。
    然后使用yum update，它会检查每个要更新的软件包的头，得到一些信息，包括软件包的大小等等。

    会计算出总的要下载的大小，问你是否要下载。
    乖乖，一共590m， 我选择了y，开始下载……

    漫长的等待。
    然后会提示你，你再选择y确定一下就好。
    弄完后半死，重启一下后一切正常。

    但重启时发现，启动时选择系统的时候linux有了两个选项，只有版本信息的微小差异。倒是不影响你选择进入linux
    就是看得不是很爽。于是上网搜索了一下，知道这个信息由 文件系统/boot/grub/grub.conf来决定。
    于是研究了一下它，删掉了那个版本比较旧的选项，再把默认启动系统改为default = 1 （因为现在是两个从0开始编号，windows是1，一开始三个的时候，windows是2）

     至此，更新彻底完成！

    考研归来，不甚理想，等成绩中。

复习考研中…… 这里就暂不耕耘了……