OpenGL ES 紋理圖檔解析第一波 - 無耐地放棄重寫這一部分

OpenGL ES 紋理圖檔解析第一波 - 無耐地放棄重寫這一部分

太陽火神的美麗人生 (http://blog.csdn.net/opengl_es)

本文遵循“署名-非商業用途-保持一緻”創作公用協定

轉載請保留此句：太陽火神的美麗人生 -  本部落格專注于 靈活開發及移動和物聯裝置研究：iOS、Android、Html5、Arduino、pcDuino，否則，出自本部落格的文章拒絕轉載或再轉載，謝謝合作。

重寫，意味着有個參照，當然啦，我是參照老羅同志的示例代碼。

可是紋理圖檔解析這一部分，真的好多東西，之前已有發主要部分，但那個确實經不起推敲，還有好多相關的參數解析，确實搞不太清楚。

是以還是覺得老羅的兩個類寫的比較内斂：TextureLoader 和 TextureHelper，直接調用一個類方法，傳一個圖檔路徑就能得到紋理對象：

tempMaterial.textureUnit = [TextureHelper createTexture:textureImagePath isPVR:FALSE];
           

細節問題，全部掩藏起來，不失為上等代碼與結構。

不過，不要高興的太早了，如果你的紋理圖檔不在應用包中，而是在應用沙盒裡，那麼這樣的簡單使用，就要出問題了，一看下面代碼，就全明白了：

@implementation TextureLoader

- (void)loadImage:(NSString *)filepath isPOT:(Boolean)isPOT
{
    [self unload];

    NSString* resourcePath = [[NSBundle mainBundle] resourcePath];
    NSString* fullPath = [resourcePath stringByAppendingPathComponent:filepath];

    UIImage* uiImage = [UIImage imageWithContentsOfFile:fullPath];
           

從上面代碼中，可以發現，紋理圖檔都是應用包内的路徑，也就是開發應用時直接預置裡面的圖檔資源。

那麼我們要想使圖檔靈活起來，想放哪兒就放哪兒，那就得讓其目錄可配置，怎麼辦呢?

有人說，那就把增加個路徑屬性，或者将 resourcePath 改成類的屬性來聲明，初始建構時給個預設值是應用包路徑，這樣如果還是原來的使用方式，預設就是這個路徑，保持不變；如果指定了新路徑，那麼就按新路徑來搜尋。如下：

@interface TextureLoader : NSObject
@property (nonatomic, strong) NSString* resourcePath;
           

@implementation TextureLoader

- (id)init {
    
    self = [super init];
    if (self) {
        
        self.resourcePath = [[NSBundle mainBundle] resourcePath];
    }
    return self;
}


- (void)loadImage:(NSString *)filepath isPOT:(Boolean)isPOT {
    
    [self unload];
    
    NSString* fullPath = [_resourcePath stringByAppendingPathComponent:filepath];
    UIImage* uiImage = [UIImage imageWithContentsOfFile:fullPath];
    
           

經過以上的修修改改，就可以在幫助類中，增加個路徑參數了：

+ (GLuint)createTexture:(NSString *)textureFile isPVR:(Boolean)isPVR {

    return [self createTexture:textureFile textureDir:nil isPVR:isPVR];
}

+ (GLuint)createTexture:(NSString *)textureFile textureDir:(NSString *)textureDir isPVR:(Boolean)isPVR {
    
    TextureLoader * loader = [[TextureLoader alloc] init];
    if (nil != textureDir) {
        
        loader.resourcePath = [NSString stringWithString:textureDir];
    }
           

記得，原來的函數名要保留，如上面的方式，這樣原邏輯完全沒變，隻是多一次調用，對于現在的手機，也是影響不大的。

經過以上的修改，是否感覺功能已經實作了呢？好像，差不多，基本上吧，能指定目錄了。

不過我這裡重心，不是要說這些個路徑的操作問題，而是要重談面向對象程式設計的準則，不清楚的可到此檢視一篇别人的文章，簡單概要如下：

1、單一職責原則（Single-Resposibility Principle）

2、開放封閉原則（Open-Closed principle）

3、Liskov替換原則（Liskov-Substituion Principle）

4、依賴倒置原則（Dependecy-Inversion Principle）

5、接口隔離原則（Interface-Segregation Principle）

我們這裡，要涉及的是 2、開閉原則 ：

Software entities(classes,modules,functions,etc.) should be open for extension, but closed for modification。

（軟體實體（類、子產品、函數等）應當對擴充開放，對修改關閉，即軟體實體應當在不修改的前提下擴充。）

那麼，我們上面所做的事情，真的有違這個原則噢！

有人說，這些個原則不用特意遵守，沒啥用，寫了好代碼就行。

不過，我已經看到潛在的危險可能發生，一旦，我上面的修改再複雜點，出現問題，我想回到前面的思路，都有些困難。

什麼SVN版本控制，什麼......在這些小細節處，真的不起太大作用，做過實際開發，都了解的，您不會沒做過開發吧！什麼？一兩年？噢，那可能你連基本技術都沒掌握熟呢，估計這些感受确實還沒有，報歉，請看上半部分即可。

第2條原則，其實，就是讓我們再加一個重載方法而已，不要改原來的，

一是，確定不給原系統引入風險，畢竟原系統是經過反複測試驗證過的；

二是，修改真正出現問題，可以直接轉回原系統代碼，無縫割接或零延時割接（這是電信術語，花架子，胡弄人兒的漂亮詞兒）；

三是，不過我還有一種了解，第2條原則，從某種角度，讓代碼本身就變成了一個即時可見（俺也學着用些花花詞兒）版本控制庫。

隻要你用過的，好用的，經過反複測試确認沒問題的代碼，在這份代碼中，就會保留下來，後續沒有修改，隻有新加和擴充。

新加和擴充的一旦出現問題，就可以直接在代碼中進行對照，無形的版本控制系統。

曾經有帶過的新入行小兄弟兒，抱怨局方一天都能有好幾遍修改意見，問一回一個樣，不過我見到局方，基本沒見着這些修改。

因為，隻要是局方的要求，就一定要在代碼中留有痕迹，最後注釋寫明，當你再遞交時，重申之前對要求的了解。

并且，局方的人轉多大圈子，都萬遍不離其中那幾樣，都留着，給他看清楚，按他的要求割 接代碼就完了。

說來，并不是局方的人要玩死你，是因為他也不知道該咋辦，随便給你個信号，你自個猜去吧，反正球踢給你了，責任不在他。

如果你沒這麼做，被局方人玩死，那是活該，誰讓你懶了呢？！多寫幾行代碼能累死你，況且更多是直接調用或者拷貝。

遇到這種情況，你全列出來了，他就沒的話說，隻能推拖：

一可能是，你的了解力太差

那麼，不妨就當面承認，确實了解力比較差，請他再給指點一二，然後複述給他聽，他确認後，是否要求他簽字，這個得看情況而定了，涉及到撕沒撕破臉的火侯問題；

二可能是，他也得現分析，根據他們局方的實際情況，最終算出個大概的規模和細節，然後還是要給你一句話，“跟你這人打交道真是繁複”

這個沒辦法，你的目的是索要到真正的需求，而這些需求是我們沒辦法自個瞎定的，他們又懶得分析，或者更準确地說，是怕擔責任。

如果最終還是拿不出明确的需求來，這時侯無論他有沒有這些個爛話跟着，都不重要了，問他要時間，态度依然謙遜，别讓他抓到把柄，再以你态度不恭為由擱置你，是這種小人常幹的事兒。

如果時間給不出來，那麼球在他那裡，他無力往出傳球，那立即把這事兒向上彙報，有多大捅多大，這樣有兩點好處：

一、這事兒，大家都知道了，他想再整貓屎往你身上甩，是不太可能的了；

    怕他記恨，再陰你？那上面說的就不是在陰你嗎?!時間久了，陰你就成家常便飯了，那時真是無力回天。

二、發現問題，你及時上報，你沒責任，如果你不及時上報，他的上司，還會以你沒有及時上報為由，打你個閃不及，即使是，暗中都已經知道了；

三、最後也是最關鍵的，我們謙虛作人，勤奮做事，還常被小人陷害，那一樣是我們自已的錯：

a、上面的你做到了嗎？謙虛了嗎？真誠了嗎？低調了嗎？沒有的話，就繼續做好再說！

b、你有讓打你的人知道，他的手也很疼嗎？沒有，那麼下次你再挨打，活該！婦人之仁，難成大事；

      殺敵一千，自損八百，在某些情況下，也是必須硬着頭皮上的事情，要不然，你這八百早晚都讓人家不費一兵一卒給幹掉，至少自已還留有二百再生力量，而使敵人無生還餘力

我們以解決問題為目标，一般是不會碰到這些個爛事兒的，經過溝通協商都能得到有效解決；

如果真的遇到上面的五花八門的人和伎倆，那麼不妨一試，前提是你自已做得夠好，讓人挑不出大毛病。

至于被冠以什麼樣的說詞，那個不重要，無能的人總是會給自已找很多理由，背後說三道四，當着面兒，為什麼不把事情說清楚，說得他啞口無言的時侯，他默不做聲，就等着回頭背後使黑刀子，這樣的人，就叫小人，俗話講：小人常戚戚，就沒什麼好怕的了。

就一個不遵守面向對象設計原則2，就牽扯出這麼多實際發生過的事情，兩種做法，兩種截然不同的結果，前者可能最後變成了奴隸，直到項目結束，你就祈禱别出問題，一旦有問題，人家都不怕，因為有你這個屎盆子，随時可以拿來上去晃兩下，有接着的！後者，可能走後，背地裡，不少壞話等着，不過至少我們是幹事情的，當着面兒，話能說得出，舌頭能捋得直，甚至，可以找茬，用他們背後說你的壞話，當面兒來埋汰對方，這個得看時機，而且看火侯，迫不得已不要這樣，除非你需要讓對方難受時，才這樣做。

為什麼要讓對方難受？真是傻呀！他不難受，他就騰出空兒來，讓你難受，當你覺得難受時，你得明白為啥難受啊，知道是他讓你難受的，你就要給他個更大的難受，讓他自顧不睱，哪還有工夫來玩你了。

其實，我們真的都是本份人，不過本份人，更應該能看懂一些事情，才能自我保護。

《菜根譚》有講“出污泥而不染、知機巧而不用”，看了十年的書了，越來越感覺能明白的詞句要比十年前多些了。

出污泥而不染，明機巧而不用

勢力紛華，不近者為潔，近之而不染者尤潔；智械機巧，不知者為高，知而不用者為尤高。

【大意】

權利和财勢，以不接近這些的人為清白，接近而不受污染就更為清白；權謀術數，以不知道才算高明，知道而不使用就更為高明了。
           

不過，以上僅是針對沒有明确需求的情況。

雖然需求始終在變，但至少，對于上一次明确的需求，你的工作成果得到确認，或者由需求改變而帶來的開發周期的延長，這個都屬正常的事情，靈活開發，就是要擁抱變化。

不過一般需求變更人，常會為了推拖自已之前需求給的有問題，或者有了新的想法，确不想為之前自已的膚淺需求而埋單，是以故意把這個責任推給開發方，這也是靈活開發經常難以有效實施的原因之一。

對此，如何解決，欲知後事如何，且聽下回病好了，再分解！

好了，面向對象設計原則引發的另一樁血案，到此告破，謝謝大家。

我也該吃藥了，感冒一天重于一天，晚上睡不着覺，這兩天還要駕考，年關、年關，年年過難關啊！