基于自然语言的软件工程和程序设计（下）
软件发展至今，无论是编程语言，还是软件工程，乃至是互联网的趋势发展，都是飞速发展。于是，我们便迷茫于这样形形色色的语言和概念之间，无所适从。其实，我们不妨返璞归真，回到最初，让我们从语义出发，来讨论这形形色色的种种，你是否恍然大悟呢？
前文索引：
10. 面向对象与语义分析
我们都知道，面向对象是自顶向下的分析过程和自底向上的设计过程。在这里，首先，我们先不谈分析过程，只谈设计过程。
系统有多少个类，不是一拍脑袋想出来的，不是经验累积而成的，而是根据需求分析中提炼出来的。
类的产生是名词提炼的过程，我们知道，每个对象都是对应着现实中的一个实体，而每个类都是对具有相同特征的对象的抽象。越是恰当的抽象，我们就越能提炼出精确的类。
这时，让我们不得不感叹古人诗词的精妙：
枯藤老树昏鸦，小桥流水人家，古道西风瘦马。夕阳西下，断肠人在天涯。
诗词，是对文章高度的抽象过程；面向对象的设计过程，也是对现实世界的抽象过程；何时，我们能将需求分析文档精确提炼成古诗词，此时乃大悟面向对象之道也。
11. 设计是违反语义的过程
与其说面向对象可重用，易维护，不如说面向对象更贴近我们的现实设计，让我们的每一个类的产生都有章可循。此乃为面向对象之妙也。
在之前的一部，我们将现实社会映射成了我们的程序中对应的类，可是这时肯定会有人跳出来说，这是面向对象么？继承，多态，封装，你这什么都没有啊！
这就是我在本节中要提到的，在我看来：设计是一个违反语义的过程。
例如：”老师讲课，学生听课。“这样的语义环境，自然会产生老师和学生两个类，可是大家这时都会想到，此时应该提取出来”人“作为老师和学生的基类（父类）。可是，我们知道，人在此语义中是不存在的，他只是我们根据经验来假设出来的。我们在之前说过，类是对对象（现实事物）的抽象，而父类又是对类的再抽象过程。因此，我认为：继承是对抽象的再抽象。
提到设计，我们就要提到设计模式，我们来想想常见的设计模式，工厂，适配器，策略等等，这些在我们的语义中都是无法分析出来的，因此，在我看来，设计模式实际上是牺牲了语义的自然性，来换取软件的可重用性和可维护性。
12. 数据库设计与自然语义的冲突
在此，我指的数据库特指关系型数据库。因此我说，数据库设计与自然语义的冲突，其实就是说关系型数据库与面向对象语言之间无可调和的矛盾。
换句话说，在面向对象中，属性不一定是原子的，数据也不一定没有冗余，因此数据库的三大范式对于面向对象设计来说，是不适用的，这也就间接导致了，关系型数据库和面向对象设计时冲突的。
（注：由于本人对 ORM了解甚为，以下言论请大家选择性相信，也希望大家不吝赐教）其中ORM就是为了解决面向对象与关系型数据库不匹配而产生的技术。很多人在用ORM时有一个误区，就是首先建立数据库，然后由数据库生成实体对象，但是在我看来，数据库只应该是存储数据的工具，而绝不应该成为整个项目设计的核心，正确使用ORM的办法应该是把程序自动持久化到关系数据库中，而我们在程序中对数据库是一无所知的，我们操作的只是一个对象的集合罢了。我不清楚ORM当今的发展，但是在我看来，一个完美的ORM系统应该具备解析对象，然后将对象转换为符合范式的数据库结构的能力。
另外，视图和缓存表也是解决方案之一。
最后，我们只能期待对象型数据库的进一步成熟了。
13. 我眼中的未来语言
在我眼中，语言的发展方向应该是逐步贴近语义，试想从第一代语言发展至今，语言的趋势无非是越来越适合于程序员使用，提高程序员的工作效率，说句再难听些的，就是逐步降低系统开发程序员的门槛，其体现一者在于方法封装的逐步完善，二就在于越来越接近自然语言，越来越接近“大型作文”的写作过程。
那么当软件发展到一定程度，我认为未来的语言是等同于自然语言的程序设计语言。从而人人可编程，方法高度封装，编译器可识别人们的自然语言语义从而转换成机器可识别的语言。我们需要做的只是把需求整理成“无语病”的需求分析文档，然后把文档移交给“编译器”，返回给我们的是一个个.exe，.aspx。
也许到了那一天，程序员这个职业不复存在了，取而代之的是作家，这一天，我们说，软件真的发展到了最高阶段。
