奇门遁甲排盘软件略谈
不在于结构有多复杂，而在于结构能否满足需要。整体上软件纵向横向均有相应的层次，本软件是典型的“不经大脑思考”、“无完备预先计划”的，许多结构是在一步步的制作与重构过程中变化的。
由于在Smartphone上的性能比较重要，一开始最先考虑到的就是：
1、日后修改为WEB版与PC版时，只用重写界面部分
2、日后有可能打算往Java平台上迁移，故一些C#语言特性的东西需要放弃
3、无论是Smartphone还是WEB还是PC版，软件自身的界面布局必须是可定义的
4、日后需要增强格局分析之类的功能，针对字符处理的分析效率远远低于数据运算的效率，故在分析一类的功能上，不能是针对界面层显示来的，应该是针对内部的数据结构。
针对上述三个特色，初步的构想就是：
在界面层显示与其它软件部分之间，需要一个专门的映射层次，在这里，命名的是类的ViewCovert，为了能够在色彩渲染上很易扩展，因此，此处分别建 立为两个类，一个为ViewCovertBase抽象基类，专门负责符号的映射与扩展中必要函数的定义，这里这样考虑的原则是本层次要在尽可能不更动的情 况下，给界面层最大的灵活层，而ViewCovert类中，则包含着具体需要变动的类。ViewConvertBase类本身并不仅仅是一个类， ViewCovert类原则上不仅仅是ViewConvertBase的子类，它本身还负担着为接口映射界面提供完整数据的功能。故此处， ViewConvert本身还需要承担接口功能。所有的界面显示所需数据均需要自ViewConvert类处获取。
在本质上，ViewConvert作为映射层次，它本质上应该是一个适配器。
在界面层部分，主显示格局的窗口主要包含的应是绘制功能，在此处为了结构的清楚，不得以要牺牲少许性能，颜色的渲染要通过识别具体的文字来进行，并非在后台逻辑处理部分就确定颜色。
由于软件是可配置的，配置代表的是一个公共环境，应该具有是唯一实例，这里第一想到的就是需要一个公共的静态类实现配置功能，有一些极度唯心的人认为公共 函数或变量是非常不利的，用传值的办法最好，因此只能用传值，这里绝不敢苟同------与其传值传得晕晕乎乎，不如用一个公共值来获取比较好。以前处理 图形时，琢磨过，发现，纯静态类静态变量与类的性能没有单件的效率高，为什么我也不清楚，由于这里与单件比较累，在性能不没有到必要优化的地步时，先不管 它，目前先全部采用静态来实现。
配置功能的处理与实现，全部是在界面层完成的。界面的意义并非是呈现界面给用户，它完整的含义是与用户交互。而在后台逻辑中，需要用于的配置部分，也是直接从此静态类中猎取的，因此，就有了，配置部分的值写入是在界面层完成的，而读取它，则在任何一处都有可能。
这样的模型让人感觉似乎哪里不完美，仔细想了一下，此类并不会对系统造成什么影响，即使突然想拆除掉配置功能中的函数，也是可以轻易完成的(借助于伟大的编译器)，故此处的考虑在维护上来说，不会造成不可预计的影响，同时这样的实现也是“立即换肤”的较理想的手段。
日历方面了，日历需要将日期转换为干支，因为此处的运算是不可避免的复杂，因此，此处必须仔细考虑如何保证较高性能的同时提供干支动态转换的需要。
把所有干支存下来用空间换时间是不可能的，因为所有的干支存储下来的话，数据量难免太大，即使自1900年起算，至2032年也有132年，干支要细到小时，因此这里处理出来有起码几万条数据，对于smartphone来说，空间与效率是不现实的。
如果计算的话，理论上年的计算是最简单的，找一个甲子年，找到年份，然后看过了几年，再看是否过了春分，即是否要另外重新建一新年，就可以非常快速地决定。
对于月来说，就比较麻烦，首先每月是根据节气而定制的，凡与月有关的术数，必然与节气有关，在这里，首先就要处理节气功能，经过仔细思考，做了一个节气转 换的小工具，把2000年~2032年的数据制作成了节气数据字典，大小在4K左右，考虑了一下，既使加入到1900年的，容量会大4倍，再加每条数据多 出来的2个字节，容量极有可能在16K左右。目前暂用的是4K数据，检索效率目前极度满意(瞬间)，但如果是16K的话，检索效率又会如何？头痛，未敢尝 试。
真太阳时数据，真太阳时数据也是需要制作数据字典，与上面是相同的，制作出来约有2K左右，虽然感觉还是大了些，还还是可能接受的。
打算尝试一下，如果在内存中解压数据，效率上空间会快还是会慢？Smartphone的IO读写效率虽然不高，但运算效率非常高是肯定的。
由于在Smartphone上的性能比较重要，一开始最先考虑到的就是：
1、日后修改为WEB版与PC版时，只用重写界面部分
2、日后有可能打算往Java平台上迁移，故一些C#语言特性的东西需要放弃
3、无论是Smartphone还是WEB还是PC版，软件自身的界面布局必须是可定义的
4、日后需要增强格局分析之类的功能，针对字符处理的分析效率远远低于数据运算的效率，故在分析一类的功能上，不能是针对界面层显示来的，应该是针对内部的数据结构。
针对上述三个特色，初步的构想就是：
在界面层显示与其它软件部分之间，需要一个专门的映射层次，在这里，命名的是类的ViewCovert，为了能够在色彩渲染上很易扩展，因此，此处分别建 立为两个类，一个为ViewCovertBase抽象基类，专门负责符号的映射与扩展中必要函数的定义，这里这样考虑的原则是本层次要在尽可能不更动的情 况下，给界面层最大的灵活层，而ViewCovert类中，则包含着具体需要变动的类。ViewConvertBase类本身并不仅仅是一个类， ViewCovert类原则上不仅仅是ViewConvertBase的子类，它本身还负担着为接口映射界面提供完整数据的功能。故此处， ViewConvert本身还需要承担接口功能。所有的界面显示所需数据均需要自ViewConvert类处获取。
在本质上，ViewConvert作为映射层次，它本质上应该是一个适配器。
在界面层部分，主显示格局的窗口主要包含的应是绘制功能，在此处为了结构的清楚，不得以要牺牲少许性能，颜色的渲染要通过识别具体的文字来进行，并非在后台逻辑处理部分就确定颜色。
由于软件是可配置的，配置代表的是一个公共环境，应该具有是唯一实例，这里第一想到的就是需要一个公共的静态类实现配置功能，有一些极度唯心的人认为公共 函数或变量是非常不利的，用传值的办法最好，因此只能用传值，这里绝不敢苟同------与其传值传得晕晕乎乎，不如用一个公共值来获取比较好。以前处理 图形时，琢磨过，发现，纯静态类静态变量与类的性能没有单件的效率高，为什么我也不清楚，由于这里与单件比较累，在性能不没有到必要优化的地步时，先不管 它，目前先全部采用静态来实现。
配置功能的处理与实现，全部是在界面层完成的。界面的意义并非是呈现界面给用户，它完整的含义是与用户交互。而在后台逻辑中，需要用于的配置部分，也是直接从此静态类中猎取的，因此，就有了，配置部分的值写入是在界面层完成的，而读取它，则在任何一处都有可能。
这样的模型让人感觉似乎哪里不完美，仔细想了一下，此类并不会对系统造成什么影响，即使突然想拆除掉配置功能中的函数，也是可以轻易完成的(借助于伟大的编译器)，故此处的考虑在维护上来说，不会造成不可预计的影响，同时这样的实现也是“立即换肤”的较理想的手段。
日历方面了，日历需要将日期转换为干支，因为此处的运算是不可避免的复杂，因此，此处必须仔细考虑如何保证较高性能的同时提供干支动态转换的需要。
把所有干支存下来用空间换时间是不可能的，因为所有的干支存储下来的话，数据量难免太大，即使自1900年起算，至2032年也有132年，干支要细到小时，因此这里处理出来有起码几万条数据，对于smartphone来说，空间与效率是不现实的。
如果计算的话，理论上年的计算是最简单的，找一个甲子年，找到年份，然后看过了几年，再看是否过了春分，即是否要另外重新建一新年，就可以非常快速地决定。
对于月来说，就比较麻烦，首先每月是根据节气而定制的，凡与月有关的术数，必然与节气有关，在这里，首先就要处理节气功能，经过仔细思考，做了一个节气转 换的小工具，把2000年~2032年的数据制作成了节气数据字典，大小在4K左右，考虑了一下，既使加入到1900年的，容量会大4倍，再加每条数据多 出来的2个字节，容量极有可能在16K左右。目前暂用的是4K数据，检索效率目前极度满意(瞬间)，但如果是16K的话，检索效率又会如何？头痛，未敢尝 试。
真太阳时数据，真太阳时数据也是需要制作数据字典，与上面是相同的，制作出来约有2K左右，虽然感觉还是大了些，还还是可能接受的。
打算尝试一下，如果在内存中解压数据，效率上空间会快还是会慢？Smartphone的IO读写效率虽然不高，但运算效率非常高是肯定的。
