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相應的產品。。。。
真心覺得有些多餘了。