面向问题，而非面向对象

软件要解决的核心问题只有一个：输入-输出问题。

对于任何一个用户来说，他们并不关心这个中间过程是如何实现，对于他们来说，他只关心输入什么，输出什么。

总之，输入越快、越简单、越少、越智能越好，输出越快越有效越好。

输出并非越多越好，满足当前最迫切的需求，才是最重要的。

对于终端用户来说，管你什么云计算，云存储，they don't care.

他们就想要的就是最简单的输入，然后立刻得到他们现在迫切想得到的结果。

比如，钢铁侠眨个眼睛，钢盔就飞过来，眨眼就是输入，输出就是装备初始化，

再比如，走在大街上，不需要傻乎乎在手机上敲入几个字符开始导航，导航地图自动输出，

你走路的动作、意图分析和当前GPS信息就是输入，输出是导航地图、当前路况。

软件最有力的创新点和竞争点，无非是在这两方面去下功夫。

1. 输入问题：

标准：键盘、鼠标、移动设备触屏手势重力传感器

定制：游戏操作杆，汽车方向盘

高级：语音输入、体感输入、脑电波、其他生理信号和综合信息

对于标准输入来说，没什么好创新的，该做的，别人都做完了。

脑电波输入，我见过有这样的产品（老美做的），但是距离真正的产品化，还很远。

目前来说，输入最快，而且相对比较成熟的方案就是语音输入。

详细细节，请参照《钢铁侠》123.

可以预见，语音识别作为大部分程序的输入辅助工具，是迟早的事情，

虽然我们并不是从事语音识别工作，但是也需要考虑到如何将语音识别模块接入到当前程序中来。

到时候，语音识别一来，你得把原来的产品全都推到重写一遍，未免太low了。

多少需要考虑下，当前程序对于未来多种输入手段的可扩展性，

未来需要语音应用，直接和第三方合作，就可以了。

即使用不到语音，也完全可以让你的程序兼容，自动化执行脚本，方便回归测试。

Command Control Module, 和 Context Manager Module, 是需要考虑进去的。

关于语音识别，有两个问题需要考虑：

1. 我个人感觉机器学习应该会应用到，

因为每个人的口音不一样，让一种程序去完成这项工作，肯定难度太大，准确率不高。

试想钢铁侠如果操着一口标准四川腔，那估计发生空难的几率很高。

我个人感觉比较靠谱的话，应该会用到一个机器学习模块，

我认为认为机器学习的思想是（我没学过机器学习，说得不对，就当我胡说八道），

先不做这样的假设：认为某个语音和某个字符是一一对应关系，

而是事先准备一个训练集，

应该会得到同一个语音和某几个字符的对应关系，（或者多对多的对应关系），

同一个语音，它有可能是对应A，对应B，对应C字符，

随后训练的进行，该语音在某个句子里对应A的几率的在逐渐上升，

那在这个句子里，该语音就会被认为是A字符。

或者反过来推测这种关系。

2. 语音的特征提取，如何定义一个语音，

我的理解是语音信号就是一个波形图，对波形进行傅里叶变换，就会得到语音的频率分布特征。

我估计猜得也八九不离十了。

2. 关于输出问题：数据，报表，图表，文档，图形，语音，视频

输出的问题，很难总结，除了要求快点拿到结果以外，

更重要的是让用户拿到他立刻想要看到的东西，而不是在于多，

给用户展现的界面，应该是越简单越好，简单即是美。

当然，在后台，你应该准备尽可能多的东西，总之，把自己想象成机器猫就对了，

你要什么，我给你什么，而且兜里还有惊喜哦。

------

PS. 关于面向对象

面向对象无非就是那些设计模式，不能说面向对象没用，如果你刚入门的时候，在讨论这个，还说得过去。

但是都多少年过去了，你还停留在这阶段，说明这么多年，你都白混了。

实际上，编程已经开始越来越简单化了，关于那些模式，你第一次写的时候，感觉挺好玩好神奇，

但这些重复的模式代码，你都写了一万次了，你就会觉得恶心了，

比如创建一个线程，就需要创建一个临界区，还要上锁，写那么多重复代码，并没什么好玩的。

不光你自己会觉得二，那些大师们会觉得很二，所以越来越多的高级语言在发明，

关于这些设计模式型的问题，大部分在语言层面就跟你解决了。

虽然，c++号称是效率最高的语言，但是天天写这些重复代码，也并没有把它的性能给体现出来。

所以，面向对象没什么好说的，设计模式动手写一遍就行了，这只是基础，没什么创新点可言。