0x01 ：计算模块（Core）和前端对接
首先特别结对编程刘乾组(SivilTaram)提供的计算模块（Core），http://www.cnblogs.com/SivilTaram/p/4859934.html
在Core模块的说明文档中，我们可以清晰发现在计算模块Core主要实现了表达式计算、四则运算表达式生成、题目文件和答案文件的审核的功能；
但在设计思路上：
在整体的设计思路上，SivilTaram组的Core模块同样将写入和读取文件的逻辑封装在计算模块中；但在自己的前后端的设计中，完全将计算模块设计为单纯的计算功能
在参数设置的方式上，SivilTaram组的Core将全部的setting更改为XML文件的读写，在自己在Core上将setting全部嵌入到计算模块中，但是由于XML文件的读写和setting的实现方法并没有引起较大的冲突，仅在“设置”部分调用了此函数，因此，我们这里完全能够通过XML的读写函数来封装setting函数；
在文件的读写中，SivilTaram组的Core直接将试题的生成和答案的生成直接写入文件，而自己在设计中将文件的读写全部置于前端，计算模块仅生成能够读写入文件的内容（string或string[]类型等），这里我们不妨在此将CoreInterface接口的内容再次列在下面
interface CoreInterface
{
void setting(int MinRange, int MaxRange,
int minOp, int maxOp, long number,
bool isFactor, bool isDecimal, bool isMin,
bool isBracket, bool isMul);
bool setJudge();
string CreateSingleExpression();
string[] CreateExpression();
string[] CorrectionJudge(string exercise, string answer);
string Calc(string formula);
}
因此，考虑到整体的设计思路我们不妨可以通过读写临时文件ConfigurationTextForWinform[1-3].txt的方式，将SivilTaram组的Core中写入文件的部分重新读写，并通过中间层实现SivilTaram组的Core模块由中间层ConfigureCore : CoreInterface解析为基本的自己的Core的方法，从而使得前端几乎不需要任何修改，即可实现前后端的耦合，总体用于中间层的代码量不超过100行，因此得益于前端较高的独立性，和SivilTaram组功能封装明确的Core模块，最终整体的耦合并未花费较长时间，但在耦合的过程中也存在了一些问题，不妨将它简单罗列与0x02中，将此分享
0x02 ：计算模块（Core）和前端对接中的问题
0x0204 ：前端模块和计算模块
首先开启对自己计算模块和前端模块的吐槽部分，在耦合的过程中，在基本功能的实现中，即表达式计算、四则运算表达式的生成、题目和答案文件的检测，由于在封装的过程中完全调用了Core实现的接口，此过程并没有出现其他问题，整体耦合相对较优；但在额外添加功能的过程中，由于涉及已知答案和目标答案的比较，这里由于用户的输入可能存在浮点数、真假分数、带分数等多种不同形式的表达，因此这里采用设置精度e的方式，通过全部解析为decimal类型的数据，进行“约等于”的比较；这里由于扩展功能时为想清楚这其中必要的联系，不得以采用基础类Factor和ParseNumber方法类保证此部分功能的实现，导致前端中不仅存在了Core的计算模块，还包含Factor的基础模块，使得前后端的耦合过程中，若不取消试题挑战功能，必须保留Factor基础类。但最终，通过Core.Calc的方法直接获取结果的字符串形式，最终在前端封装private decimal(string result)函数和private bool near(string resultA, resultB, precision)函数来实现这一过程，避免对底层类的调用。
0x0208 ：.NET框架的安装说明
事实证明在处理意外问题上总是拖延了过长的时间，由于SivilTaram所提供的dll文件是基于4.5.2 .NET Framework框架生成，因此在耦合过程中会存在警告信息,“ 未能解析主引用“Core, Version=1.0.0.0, Culture=neutral, processorArchitecture=MSIL”，因为它是针对“.NETFramework,Version=v4.5.2”框架生成的。该框架版本高于当前目标框架“.NETFramework,Version=v4.5“”，因此，我们这里需要在VS 2013中配置.NET Framework 4.5.2框架，这里中间经历了一定的时间，具体的方法说明于如下链接：
http://stackoverflow.com/questions/31189154/how-do-i-get-visual-studio-2013-to-allow-me-to-target-net-framework-4-5-2
这里额外说明，一定要下载Developer Pack Of the .NET Framework，否则在配置过程中VS2013的目标框架中将始终不存在这一选项
0x0208 ：.NET框架的安装说明
这里展示部分的代码框架来说明中间层的设计思路
public class ConfigureCore : CoreInterface
{
private Core.Configure con;
private static long tick = DateTime.Now.Ticks;
public static Random rand = new Random((int)(tick & 0xffffffffL) | (int)(tick >> 32));
public ConfigureCore(Random rand)
{
ConfigureCore.InitialXmlFile();
rand = ConfigureCore.rand;
}
public void setting(int MinRange, int MaxRange,
int minOp, int maxOp, long number,
bool isFactor, bool isDecimal, bool isMin,
bool isBracket, bool isMul){}
public bool setJudge(){}
public string CreateSingleExpression(){}
public string[] CreateExpression(){}
public string[] CorrectionJudge(string exercise, string answer){}
public string Calc(string formula){}
//XML Part For Inital Of UI
public static void InitialXmlFile(){}
private static void CreateNode(XmlDocument xmlDoc, XmlNode parentNode, string name, string value){}
public static string ChangeXml(string name, string NewValue){}
public static string ReadXml(string name){}
}
0x03 ：计算模块（Core）和前端对接中的反思
最终，在几乎未改动前端模块的前提下，通过中间层的搭建完成了SivilTaram组的Core计算模块和自己UI前端的耦合，总体而言，此次中间层的代码量并非很大，但在此附加题的过程中也主要存在着一些感想：
接口设计思路：在从需求分析到设计部分，在起初自己忽略了前后端的功能划分，但在第二天的接口设计的过程想到此问题才开始重构；因此，此次接口设计思路是耦合过程中的显著问题，信息封装过程是否封装了大量必要信息导致前后端代码量出现不匹配的状况，依赖倒置原则中是否在前端中使用了过多的底层类，导致对底层类的依赖性更强，而违背这一原则等等
功能实现的区别：因此四则运算的生成和计算能够生成很多功能：从最简单的单词挑战、评分等功能的实现，因此个人认为从功能的角度，最好能将Core接口封装为单纯的计算模块，由中间层或前端完成文件本身的读写操作；因此，此次由于计算模块的接口未规定，也导致不同层次的功能封装在不同模块，耦合的时候会需要大量的中间层代码去兼容，而不是通过接口去完成耦合
结对编程的团队拼接：事实证明，愈加提前的沟通效率越是能降低后期修改、耦合的时间，如果能在结对编程中提前设计一套统一的接口，那么在前后端的直接耦合上，可能会仅需简单的参数设置完成之间的修改吧
0x04 ：尾序：写于团队编程的前夕
并非所有的记忆都被冠以再也不见的标语，
就仿佛青春算得好相聚算得好嬉戏却依旧算不好分别
既然说了再见，也一定会再次相见
散落天涯，不过是为了更好的相见
再见啦，这个骄阳似我回忆似沙春风十里不抵嫣然笑靥的夏天
一切安好~
——《夏洛特烦恼》第二章