meteortl([url]以前的(0.5.1以前)版本中的api介面為：
templatefactory 和 contextfactory 用於建立 template 和 context 兩個核心 domain,
factory 用於合併 templatefactory 和 contextfactory 兩個工廠,
builder 用於建立 factory,
engine 實現 builder，通過builder介面一步步導航到其它介面，
然而一直感覺builder介面很不順眼，
因為它與core包中的其它介面內聚性不高，
它只是作為core包其它介面的使用者，而不是被core包其它介面使用，或繼承於core包其它介面等更強一點的關聯，並且不是核心domain。
有幾個版本試圖將它移到engine包，但發現也並不妥善，
因為整體架構宣告engine包用於實現core包所有介面，
仔細研究builder的實現類engine, 發現其持有乙個不合理的configuration狀態，
public inte***ce builder
public class engine implements builder
public factory buildfactory()
}
使用者呼叫方式：
factory factory = new engine(config).buildfactory();
問題在於config只在一次建造過程有效，engine類持有它毫無意義，重構如下：
public inte***ce builder
public class engine implements builder
}
使用者呼叫方式：
factory factory = new engine().buildfactory(config);
但這樣builder就會依賴於configuration介面，
而按整體架構core包是不能依config包的，
所以只能把builder移到engine包，
發現engine例項的存在也沒起任何作用，再重構為：
factory factory = engine.buildfactory(config);
這樣，builder介面就應該刪除，
在我試著刪掉builder介面後, 猛然發現engine如果直接實現factory會更合理，如：
public class engine implements factory
public template gettemplate(string name, string encoding)
...}
使用者呼叫方式：
factory factory = new engine(config);
總結：當發現放在哪都不合理的類或介面，或許它本身就不應該存在。
C 重構之四（提取介面重構）
提取介面 是一項重構操作，提供了一種使用來自現有類 結構或介面的成員建立新介面的簡單方法。當幾個客戶端使用類 結構或介面中成員的同一子集時，或者當多個類 結構或介面具有通用的成員子集時，在介面中嵌入成員子集將很有用。有關使用介面的更多資訊，請參見 介面 c 程式設計指南 提取介面 在新檔案中生成介面...
Volley介面使用的重構
最近在做手機rom ota專案，專案不算大但原來的 耦合比較高，對後期維護不是很好，設計的好處不用多說增強 復用 更容易擴充套件 更容易讀懂 更容易維護，索性大刀闊斧逐步進行 重構 優化，其中對volley的使用也是問題比較多，所以優先重構了下，後續將逐步對各個不合理的地方重構，後面每個專案都會規劃...
Android專案重構之路 介面篇
在前一篇文章 android專案重構之路 架構篇 中已經簡單說明了專案的架構，將專案分為了四個層級 模型層 介面層 核心層 介面層。其中，最上層的介面，是變化最頻繁的乙個層面，也是最複雜最容易出問題的乙個層面，如果規劃不好，很容易做著做著，又亂成一團了。要規劃好介面層，至少應該遵循幾條基本的原則 保...