OpenGL ES 纹理图片解析第一波 - 无耐地放弃重写这一部分
太阳火神的美丽人生 (http://blog.csdn.net/opengl_es)
本文遵循“署名-非商业用途-保持一致”创作公用协议
重写，意味着有个参照，当然啦，我是参照老罗同志的示例代码。
可是纹理图片解析这一部分，真的好多东西，之前已有发主要部分，但那个确实经不起推敲，还有好多相关的参数解析，确实搞不太清楚。
所以还是觉得老罗的两个类写的比较内敛：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，就牵扯出这么多实际发生过的事情，两种做法，两种截然不同的结果，前者可能最后变成了奴隶，直到项目结束，你就祈祷别出问题，一旦有问题，人家都不怕，因为有你这个屎盆子，随时可以拿来上去晃两下，有接着的！后者，可能走后，背地里，不少坏话等着，不过至少我们是干事情的，当着面儿，话能说得出，舌头能捋得直，甚至，可以找茬，用他们背后说你的坏话，当面儿来埋汰对方，这个得看时机，而且看火侯，迫不得已不要这样，除非你需要让对方难受时，才这样做。
为什么要让对方难受？真是傻呀！他不难受，他就腾出空儿来，让你难受，当你觉得难受时，你得明白为啥难受啊，知道是他让你难受的，你就要给他个更大的难受，让他自顾不睱，哪还有工夫来玩你了。
其实，我们真的都是本份人，不过本份人，更应该能看懂一些事情，才能自我保护。
《菜根谭》有讲“出污泥而不染、知机巧而不用”，看了十年的书了，越来越感觉能明白的词句要比十年前多些了。
出污泥而不染，明机巧而不用 势力纷华，不近者为洁，近之而不染者尤洁；智械机巧，不知者为高，知而不用者为尤高。 【大意】 权利和财势，以不接近这些的人为清白，接近而不受污染就更为清白；权谋术数，以不知道才算高明，知道而不使用就更为高明了。
不过，以上仅是针对没有明确需求的情况。
虽然需求始终在变，但至少，对于上一次明确的需求，你的工作成果得到确认，或者由需求改变而带来的开发周期的延长，这个都属正常的事情，敏捷开发，就是要拥抱变化。
不过一般需求变更人，常会为了推拖自已之前需求给的有问题，或者有了新的想法，确不想为之前自已的肤浅需求而埋单，所以故意把这个责任推给开发方，这也是敏捷开发经常难以有效实施的原因之一。
对此，如何解决，欲知后事如何，且听下回病好了，再分解！
好了，面向对象设计原则引发的另一桩血案，到此告破，谢谢大家。
我也该吃药了，感冒一天重于一天，晚上睡不着觉，这两天还要驾考，年关、年关，年年过难关啊！