看到电脑上一张张美丽的航片的时候，终于是出来哦，哎！最近忙活了大半个月俺终于还是把这个工具整出来了哦。回想起来开发这个工具的时候的种种，说实话 真是折磨人哦，几易其稿，系统的架构就改过好几次哦，基本上是一个星期改一次。
在这个过程中收获还是不少的哦，痛并快乐着，不能不佩服老大的架构的思想，在英明神武的老大的指导下开发出一个基本上比较符合面向对象的软件，其中的编程思想的冲击是巨大的哦，颠覆了我以前做程序的很多固有观点。
首先来说说该工具的需求，对已有的大尺寸的航片进行切割，切割出给定宽高的航片，在提层合并航片。具体来说就是如果有一张1024 * 1024的航片切割成8 * 8张 128*128大小的航片为第零层，提层比率为2，则第1层就是原航片的256*256大小的，但是要保存为128 *128的航片 这样的航片有4 *4张，依次类推，第2层 第 3层...，还有这些航片的编号以LLXXXYYY编号，坐标原点为航片左下角，ll为层数，XXX为X轴上航片编号，YYY为Y轴上的航片的编号。
刚开始听到这个需求的时候确实是没有什么头绪，研究了一下libtiff就开始搞了哦，刚开始的时候很快就把航片的读写搞定了，以为会很快就解决问题啦，闷着头在那里狂写代码，第一版交给老大，被鄙视的不行哦，首先因为需求没有理解清楚，自己理解的图像编号和老大所说的图像编号的顺序不同哦，回过来改代码发现居然无从下手，还有就是老大要生成航片处理的结果，也无法在代码中体现。说实话当时心里还是比较嘀咕的，觉得老大交代问题没有交代清楚，后来老大说的一句话还是比较有道理的，客户的需求是不断变化的，你要是想让用户来适应你的设计是不可能的，你的设计应该是自适应的，能够应对客户不断变化的需求。听完这句话，只有无语接着在那里写代码，等我写的七七八八了，老大有空看了一下我的代码，继续鄙视我哦，为何？模块划分不清，UI层中有太多航片处理的逻辑，航片处理模块中也有太多的航片编号的逻辑。一句话 整个代码只是为做实现这个功能，毫无扩展性，如果以后在在上面添加功能基本上是没有可能。
哎！老大当时这样说了，让我修改代码，当时真是想死的心都有了哦，修改也不知道怎么下手，和老大探讨了半天，终于是定下了架构，呵呵当然啦，主要还是老大定的架构。这次交流收获还是不少的哦。
做软件首先应该定下的是输入和输出，确定数据的流向。从UI层定义输入，确定尽可能少的输入参数，从输出确定数据，输入参数到输出之间确定数据的流向，对数据的流向进行功能上的划分，确定不同的模块，模块之间尽可能少的耦合性，如果一个数据和操作是相互关联的则可以视为一个对象，对象的设计应该考虑到扩展性，尽可能的从一个基类派生，为以后扩展提供基础，使用工厂模式来确定不同的对象。还有就是UI与底层数据处理模块应该没有关联，通过一个处理模块来出来UI和底层模块之间的交换。
哎，这样做下来，我的工具有5个模块，一个处理编号生成的模块A，一个参数保存的模块B，一个处理航片读写的模块C，一个生成切割航片的模块D，一个与UI交互和与底层交互的模块E，它们之间的依赖关系为 E依赖于A D， A依赖于B， D依赖于C，这样模块间依赖清楚，接口也定义的明确。
收获哦！有一种豁然开朗的感觉，以后有机会独立开发的时候应该多想想这样的问题，争取早日有所成就哦！