Aexi计划

本文主要是介绍Aexi计划，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

又是好久都没有发布新的博客了.从今天开始要提高更新博客的频率了,那么现在开始的博客都写一些什么呢?笔者准备写一个稍微大一点的项目,并在项目的每一个关键阶段将各个过程记录下来.

那么到底是什么样的一个项目呢?

我给这个项目取名叫Aexi.是的,相信看过《Design Pattern》这本书的朋友都应该知道了，这个名字来自于《DP》这本书的第二章中的对设计模式综合运用的一个实例——Lexi.笔者准备将他使用java语言实现一遍,并实现跨平台.当然这种跨平台不是完全的write once,run anywhere.而是在尽可能改动少代码的情况下实现对多种设备的支持,这其中还应当包含对移动设备的支持.为了达到这种需求,那么就要求它对设备的视感标准的依赖应当降低到尽可能的低.所以如果它有一个具体可见的Frame显然是不合适的,适配各个平台的Frame将是一个巨大的工程,所以笔者希望它应该就是一块简单的白板,或者说它什么都没有,将与具体界面相关的代码去除,抽象成一个框架提供给各个程序员们调用,他应当具有足够的开放性以及拓展性来适应不同程序员的不同需求,当基础框架的功能不能满足应用层的程序员的具体需求时,它应当有足够的开放性以供应用层的程序员自如扩展却尽量少的影响到Framework源码.在进行博客的分析时,笔者会尽可能的复习设计模式相关知识,与读者共同进步.

                             在windows上,它应该是这样的

   

                                在Android设备上的形态

iOS设备不支持java,所以该框架无法适配到iOS设备上.

既然已经明确的项目的具体形态那么下面对这个项目的需求做一个简单的介绍,其中的部分内容与《DP》相同,当然也会有相当一部分的扩充内容.因为有前辈已经写过,所以严肃的需求分析笔者就不写了,简单易懂的需求分析如下:

1. 多视感标准:Aexi应当是跨平台的,在不同的平台上,它的样子应当是不一样的,并且在不同的平台上进行适配时,应当共享大部分代码,进行的改动是极小的.

2. 支持多窗口系统:不同的视感标准是在不同的平台上实现的,因此Aexi的显示必须与窗口系统无关.

3.用户操作:用户通过不同的界面控制Aexi,包括按钮和下拉菜单,以及底部栏(移动设备)等其他应用层程序员自定义的界面。这里要求我们对用户的操作要做到很好的封装,并且还要支持撤销的操作.

4.文本分析:Aexi应该支持多样化的文本分析功能,包括诸如拼写检查、字数统计、文本搜索替换.并应该做到当应用层程序员自定义一些分析功能时,尽可能的减少代码修改并方便扩充.

5.数学公式输入:Aexi应该支持数学公式输入.类似这种变化较大的功能,应该做到可扩充,当应用层程序员希望插入一些可编辑的特殊结构时,应该在框架搭建的体系内轻松实现插件化开发.

6.序列化:用户在Aexi上编辑的文档应当可以很轻松的序列化为各种常见的格式以便于用户长久的保存,并且这种序列化的格式也会是可扩充的,其他使用Aexi的程序员们,可以在Aexi的规则下轻松的自定义他们希望的格式.这就要求了Aexi的文档应该和显示是分离的

以上就是暂时想到的Aexi的需求了.下一篇博客会开始做第一个小功能,文字输入的光标.

这篇关于Aexi计划的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！

---