乙女的梦想

做MAD的人真的好厉害～ 

好久没更新了.....因为之前夏季综合症持续发作中，现在天气转凉，于是精神稍稍恢复。

嘛～总之前几个月一回家就会春日步上身，处于这样的一种状态，学习嘛看书嘛等各种积极向上的行为因为MP为零全部靠边去....还以补MP为名做了很多堕落的事，xgame小说动画一个没少，每天都在脑补中....

这期间稍稍有建设性的事就是我跳了一个同人游戏的坑，因而第一次和网友这种奇妙的生物有所接触....其实有时会自我反省，我是不是真的这么喜欢写程序，上班写回家也写，而且写的都不是什么高深的东西，来来去去都脱离不了民工的行列，用得着么

不过呢，这个坑确实不失为一个打发时间的好东西，当我连玩都玩腻了什么都不想做的时候，会有狐狸(策划)在背后努力的鞭策我或是我努力的抽打狐狸(喂，你们俩是M么)。最主要的是，做同人游戏的感觉是不同的，不用考虑太多的东西，yy度和自由度更高，符合我重口味的喜好(无误)。要在天朝的和谐盛世下发行的游戏中里出现同性gg之间偎依，拉小手，拥抱，kiss()的场面，基本可以定位为妄想..... 不过同人就不同了，我喜欢怎样就怎样，因为本来就是妄想的产物嘛(E和牛跳出：喂，我们定位的是友情结局，是乙女向的，这种邪恶的东西我们是不会画的)。而且，同人game的人设会更萌～嗯，在这个遍地帅哥(二次元中)的年代，光靠脸是不足以为人记住的，要帅更要有性格～嗯，这就是所谓的属性的威力了(ps.近来更加确认我萌的是变态属性....giulio大爱)

乱七八糟地扯了一堆有的没有的，其实我想说是，我应该可能大概从前阵子的颓废中恢复过来了，我要努力学习天天向上充满热情地继续生活下去(大误.....)

工厂模式

＊ 例子：

两者的都把对象的创建统一到一个地方，方便以后修改扩展，同时利用抽象类型让客户从具体类型中解耦。

我一直搞不太懂两个模式间的差别，这次终于明白了~书上原话“这个模式并不是允许子类在运行时决定产生哪个子类，而是指在编写创建者类时，不需要知道实际创建的产品是哪一个，选择使用哪个子类，自然就决定了实际创建的产品是什么。”

“利用工厂方法创建对象，需要扩展一个类，并覆盖它的工厂方法。通过子类创建对象，客户只要知道抽像类型就可以了，由子类来负责决定具体类型。”

”提供一个用来创建一个产品家族的抽象类型，这个类型的子类定义了产品被产生的方法。想要使用工厂，必须先实例化它，然后将它传入一些针对抽象类型所写的代码中。还可以把一群相关的产品集合起来。“

但我更好奇的是，是不是可以用一个类似hashtable的东西建立一个key对类的映射来代替if-else呢？不知道c和java是怎写的呢？

＊ 定义：

工厂方法模式定义了一个创建对象的接口，但由子类决定要实例化的类是哪一个。工厂方法让类把实例化推迟到子类。

抽象工厂模式提供了一个接口用于创建相关或依赖对象的家族，而不需要明确指定具体类。

＊ 设计原则：

依赖抽象，不要依赖具体。最理想状态下：变量不可以持有具体类的引用；不要让类派生自具体类；不要覆盖基类中已实现的方法。

看完大头后，早餐时间完全找不到东西看了，尝试过几本都不是太合适，要么是以我的程度需要慢慢理解的导致不知不觉间迟了出门，要么是写得很枯燥的完全看不入脑.....于是堕落地看腐杂志中......如果有什么适合十五分钟里边吃边看不会导致精神紧张而胃痛的能很轻松地随便翻着看几眼然后也会有收获的书（喂，你要求太多了吧？）请推荐我吧

装饰者模式

＊ 例子：

这个模式我觉得看例子的示意图比看类图要好…...装饰者和被装饰者有相同的超类，所以可以一层层地嵌套下去。Java的i/o就是用这样一种写法，不过书上不说我还不知道内部是这样一回事呢……

个人认为，除非想要在对大量的，行为又类似的对象间实现一些排列组合的功能效果，否则实在不喜欢这个方法，正如书上说的，产生了大量的小类，导致代码不好被理解，增加代码的复杂度，而且，若是超类的接口要变的话，用了这个模式的东西根本就是一个恶梦，那工作量怎是“民工”两个字了得……吐糟完毕，下面补类图

 ＊ 定义：

装饰者模式动态地将责任附加到对象上。若要扩展功能，装饰者提供了比继承更有弹性的替代方案。

＊ 设计原则：

对扩展开放，对修改关闭。（我还能说什么呢.....愿望是美好的，现实是残酷的）