先來看乙個開發例項：
靜態記憶體模組主要功能是根據指定的（模組號，所需記憶體大小）從某個固定的區域劃分記憶體，在執行過程中不會有申請釋放操作。
如有一塊5m的記憶體空間addr，分別有5個模組，每個模組所需的記憶體為（1mb,2mb,1mb,0.5mb,0.5mb),則各模組分到的位址如下
（addr,addr+1mb, addr+3mb, addr+4mb,addr+4.5mb)。當然還有其他的一些擴充套件功能如對齊，模組間隔離等等。
開始的實現時，先定義乙個配置表結構體，結構體有如下成員：模組號，模組要求記憶體大小，分配到的位址，其他如對齊要求等。
然後定義乙個配置表的全域性變數gastrcfgtbl，初始化函式裡根據這些配置資訊進行記憶體劃分,初始化函式如下：
int static_mem_init(void *pulstaticmem, unsigned long ulsize)
void *static_mem_alloc(int ulmodule)
這個設計初看並沒有什麼問題，功能也完成的很好。
但過了不久，新的需求來了（可惡，為什麼需求老變)，希望增加乙個新的配置表，在另外一塊靜態記憶體空間裡進行劃分（為什麼這個配置表與
老的配置表不能合併，不在本話題討論之內）。
由於已有的函式與全域性配置表資訊是耦合在一起的，**沒有變法重用。怎麼辦呢？很簡單，把原來**裡寫死的全域性變數抽取出來，作為一
個函式的引數傳遞進去，如下：
int static_mem_init(void *pulstaticmem, unsigned long ulsize, static_mem_cfg_tbl *pstrcfgtbl)
void *static_mem_alloc(static_mem_cfg_tbl *pstrcfgtbl, int ulmodule)
配置表1和2分別呼叫static_mem_init並把當前配置表資訊傳入，**就從資料耦合變成了介面耦合（介面使用了配置表結構）了，耦合程度降
低了。如下：
int config_table_***_init(void)
int config_table_yyy_init(void)
修改後的靜態記憶體模組是乙個抽象的實現，可以實現重用，增加新的需求也非常簡單。比如要求靜態記憶體不是在**的配置表寫死的，而是通
過某個配置檔案讀取，改動非常簡單，增加乙個讀取配置檔案的函式，把配置資訊讀取出來後傳給static_mem_init。
int config_static_mem_by_xml(const char *xml)
從這個例子可以看到，一種很典型的c語言開發思維：先設計這個模組的結構體，定義這個結構體的全域性變數，然後的功能**就圍繞著這個全
局變數開展。這是很過程式的一種思維，為了完成目標，按照步驟1,2，3開展，最後目標達到了，但帶來的問題就是**不夠內聚，存在資料
耦合，不能重用。
而修改後的**，熟悉物件導向的可能感覺非常眼熟，比如：
class myclass
int init_x(void)
int init_y(void)
從這個例項，給我們帶來的啟示就是：
1，需求一定要做抽象，需求是乙個具體的應用，是易變的，僵化的，不能一拿到需求就衝著目標完成了事。
2，邏輯功能實現與應用分開。記得學習資料結構時，有乙個說法是**=資料結構+演算法，全域性變數是資料結構的一種實體，不是乙個抽象的概
念。因此，在開發時應該抑制全域性變數的使用衝動。**的實現（演算法）圍繞著抽象的資料結構展開，而不是圍繞乙個具體的全域性變數展開。
先把邏輯功能實現了，再在上面新增具體的應用。這樣在實現邏輯功能時，只需要考慮實現上的正確性，而不需要考慮具體應用上的細枝末節
，**的正確性更容易保證；到了具體應用時，只需要考慮應用場景，不需要考慮邏輯功能實現，也更能把握應用場景的準確性。
3，抑制全域性變數的使用衝動。這裡感覺有必要再重複一次，如果在開發邏輯功能**時，發現需要新增全域性變數才能解決問題，則需要考慮下
**的設計是否足夠抽象，是否非加不可。
c語言中一種典型的排列組合演算法
c語言中的全排列演算法和組合數演算法在實際問題中應用非常之廣，但演算法有許許多多，而我 個人認為 方法不必記太多，最好只記熟一種即可，一招鮮亦可吃遍天 全排列 include void swap int p1,int p2 int t p1 p1 p2 p2 t void permutation i...
c語言中一種典型的排列組合演算法
c語言中的全排列演算法和組合數演算法在實際問題中應用非常之廣，但演算法有許許多多，而我 個人認為 方法不必記太多，最好只記熟一種即可，一招鮮亦可吃遍天 全排列 include void swap int p1,int p2 int t p1 p1 p2 p2 t void permutation i...
開發人員的一種新思維模式
我們正處於轉向網路中心平台的轉換過程的最初階段，這個過程漫長而又不可避免。在如何構建應用程式和分配支援業務需求所需的開發勞工這兩個方面，企業應用程式架構師和開發人員都必須採用新的思維模式。面向服務架構 soa service oriented architecture 是建立靈活 可適應和分布式計算...