在這個過程中收獲還是不少的哦，痛并快樂著，不能不佩服老大的架構(gòu)的思想，在英明神武的老大的指導(dǎo)下開發(fā)出一個基本上比較符合面向?qū)ο蟮能浖渲械木幊趟枷氲臎_擊是巨大的哦，顛覆了我以前做程序的很多固有觀點(diǎn)。

首先來說說該工具的需求，對已有的大尺寸的航片進(jìn)行切割，切割出給定寬高的航片，在提層合并航片。具體來說就是如果有一張1024 * 1024的航片切割成8 * 8張 128*128大小的航片為第零層，提層比率為2，則第1層就是原航片的256*256大小的，但是要保存為128 *128的航片 這樣的航片有4 *4張，依次類推，第2層 第 3層...，還有這些航片的編號以LLXXXYYY編號，坐標(biāo)原點(diǎn)為航片左下角，ll為層數(shù)，XXX為X軸上航片編號，YYY為Y軸上的航片的編號。

剛開始聽到這個需求的時(shí)候確實(shí)是沒有什么頭緒，研究了一下libtiff就開始搞了哦，剛開始的時(shí)候很快就把航片的讀寫搞定了，以為會很快就解決問題啦，悶著頭在那里狂寫代碼，第一版交給老大，被鄙視的不行哦，首先因?yàn)樾枨鬀]有理解清楚，自己理解的圖像編號和老大所說的圖像編號的順序不同哦，回過來改代碼發(fā)現(xiàn)居然無從下手，還有就是老大要生成航片處理的結(jié)果，也無法在代碼中體現(xiàn)。說實(shí)話當(dāng)時(shí)心里還是比較嘀咕的，覺得老大交代問題沒有交代清楚，后來老大說的一句話還是比較有道理的，客戶的需求是不斷變化的，你要是想讓用戶來適應(yīng)你的設(shè)計(jì)是不可能的，你的設(shè)計(jì)應(yīng)該是自適應(yīng)的，能夠應(yīng)對客戶不斷變化的需求。聽完這句話，只有無語接著在那里寫代碼，等我寫的七七八八了，老大有空看了一下我的代碼，繼續(xù)鄙視我哦，為何？模塊劃分不清，UI層中有太多航片處理的邏輯，航片處理模塊中也有太多的航片編號的邏輯。一句話 整個代碼只是為做實(shí)現(xiàn)這個功能，毫無擴(kuò)展性，如果以后在在上面添加功能基本上是沒有可能。

哎！老大當(dāng)時(shí)這樣說了，讓我修改代碼，當(dāng)時(shí)真是想死的心都有了哦，修改也不知道怎么下手，和老大探討了半天，終于是定下了架構(gòu)，呵呵當(dāng)然啦，主要還是老大定的架構(gòu)。這次交流收獲還是不少的哦。

做軟件首先應(yīng)該定下的是輸入和輸出，確定數(shù)據(jù)的流向。從UI層定義輸入，確定盡可能少的輸入?yún)?shù)，從輸出確定數(shù)據(jù)，輸入?yún)?shù)到輸出之間確定數(shù)據(jù)的流向，對數(shù)據(jù)的流向進(jìn)行功能上的劃分，確定不同的模塊，模塊之間盡可能少的耦合性，如果一個數(shù)據(jù)和操作是相互關(guān)聯(lián)的則可以視為一個對象，對象的設(shè)計(jì)應(yīng)該考慮到擴(kuò)展性，盡可能的從一個基類派生，為以后擴(kuò)展提供基礎(chǔ)，使用工廠模式來確定不同的對象。還有就是UI與底層數(shù)據(jù)處理模塊應(yīng)該沒有關(guān)聯(lián)，通過一個處理模塊來出來UI和底層模塊之間的交換。

  哎，這樣做下來，我的工具有5個模塊，一個處理編號生成的模塊A，一個參數(shù)保存的模塊B，一個處理航片讀寫的模塊C，一個生成切割航片的模塊D，一個與UI交互和與底層交互的模塊E，它們之間的依賴關(guān)系為 E依賴于A D， A依賴于B， D依賴于C，這樣模塊間依賴清楚，接口也定義的明確。

收獲哦！有一種豁然開朗的感覺，以后有機(jī)會獨(dú)立開發(fā)的時(shí)候應(yīng)該多想想這樣的問題，爭取早日有所成就哦！