2016/05/15
这几天,忙着做一个服务器端的小项目。
服务器接收客户端的TCP消息,消息格式中:
标识符 + 消息头 + 消息体 + 校验码 + 标识符
根据消息头中的ID字段属性,对应着多种不同的消息体。
运用简单工厂模式:
产品包括 产品抽象类和产品实体类;
1)工厂类:模式核心,含有一定的商业逻辑和判断逻辑,用来创建产品;
2)抽象产品类:具体产品继承的父类或者实现的接口;
3)具体产品:工厂类所创建的对象就是该产品的实例;
一个消息体抽象类:
//产品 抽象类 public abstract class MessageBody { public int messageID; }
多种消息体对应的实体类:
//产品实体类 /*UpdateBody*/ public class UpdateBody extends MessageBody{ public UpdateBody(){ ... } public static final int ID = 1; ... } /*RegisterBody*/ public class RegisterBody extends MessageBody { public RegisterBody(){ ... } public static final int ID = 2; ... } //还有一些就不一一列举了
工厂类(根据ID不同创建不同的消息体类):
//根据ID不同创建不同的 消息体实例: public class Factory{ public MessageBody createBody(int ID){ MessageBody messageBody = null; switch (ID){ case 1: messageBody = new UpdateBody(); break; case 2: messageBody = new RegisterBody(); break; ... } return messageBody; } }
使用的时候:
Factory bodyFactory = new Factory();
UpdateBody updateBody = bodyFactory.createBody(1);
RegisterBody registerBody = bodyFactory.createBody(2);
在ID已知的情况下,我们可以用对应的具体产品去写。然后解析不同消息体中的具体字段。
但如果是ID未知,那
bodyFactory.createBody(ID) 是?
这样不好判断,所以,在具体产品被create的同时,在具体产品内部,将各自的解析方法实现。
比如说 对于 RegisterBody:
public RegisterBody(){ //参数 略, 消息体内容
initBody();
}
initBody()
{
//根据规则 解析RegisterBody
}
这是简单工厂模式的一个应用。
那如果现在规则中 又增加了其他种类的消息体,如果继续使用简单工厂模式的话,我们就需要在工厂类创建时,多加几个case了。
工厂模式遵循 对扩展开放,对修改封闭的开闭原则。显然,当我们修改工厂类时,违背了这个原则。
于是,出现了工厂模式。
工厂模式:
1)抽象工厂:工厂模式的核心,是具体工厂必须实现的接口或者继承的父类。
2)具体工厂:含有与具体业务逻辑有关的代码,由应用程序调用以创建对应的具体产品的对象。
3)抽象产品:同简单工厂模式
4)具体产品:同简单工厂模式
抽象工厂类
public abstract class Factory {
MessageBody createBody();
}
具体工厂
public class updateFactory extends Factory {
public UpdateBody createBody(){
return new UpdateBody();
}
}
public class RegisterFactory extends Factory {
public RegisterFactory createBody(){
return new RegisterBody();
}
}
对每一个具体工厂,需要先new找个工厂,然后create相应的产品。。。。
真心觉得有些多余了。