抽象与建模

我有到时候去浏览招聘广告，请什么高级工程师要求精通什么语言....OOP，什么一两年开发经验(我这人极少说粗话，但我要说句“狗屁不通”)，有时候去面试一些人(有开发经验)，问：如何看待“类型”与“对象”，回答的五花八门，基本上书是如何说他们就怎么说。

也许我的要求太高，但不管理如何，抽象与建模是做为一个初级软件开发工程师，所必须了解或熟知的运用的概念。(如果不具备也顶多是个高级程序员的价)

题外话：在先进国家的软件教育的科目中甚少使用一些热门的语言进行教学，有甚者使用内部的语言进行教学，目的在于抛离形式语言上依赖，更注重编程思想的建立与发展。

在接下来的话题中，我会更多简要的说下，我自己对抽象与建模概念的理解，如果那里说的不对，我非常高兴接受大家的指教。

A。抽象

抽象这一词在面向对象的语言中经常的提到，那么，什么是抽象?

我是这样理解的，在众多的事物中，如果存在(发现)一个或多个共同点(可以是任何东西)，这些共同点通过某种方式可推算或验证的(也可以假定，如果不这样就没法子开发了)，

那么抽取这些共同点就成为这些事物的抽象(真理)。

从词面意思：抽取类似(象)的

这似乎与我们实际的开发没有一点联系，就算不知道抽象，还是可以进行需求分析，程序设计(建库，建类)，编码... 最后还是按时按地的交付了项目；

我对这个毫不否认，事实上的确如此，可是会遇到：

*.需求与实现不相符(客户客气的说：这个软件与我想象中的有一点不一样)

*.设计过于死板，没有适当的分离(高藕合度) (客户嘲笑的说：不是这里有问题，就是那里有问题，不怪的要定期交保护费)

*.拓展有局限，或无法拓展(客户愤怒的说：什么？我只想在业务中增加多一个审核环节也不行吗？ )

*.过于形式化 (客户无耐的说：自从使用上这个系统，我老是要加班)

当然以上这些问题还有其它的因素导致。

软件从了解领域知识，需求分析到程序设计，甚到一个算法(函数的定义)，都会涉及到抽象的概念，

如果我们无法理解抽象，就无法做到精炼（我相信学习过开发过程的都听过这个词，我的理解就是抽象后的结果），那么如何抽取这些共同点呢？

这个问题可能用一辈子的时间也说不清楚，更重要的是本人的能力有限，我只能依据开发中自己理解的情况来简单说一下：

在整个开发过程中重点之一：我们如何把实实在在的需求转换为形式化的程序语言

许多程序员在面对复杂的问题时，都不知道如何下手，好不容易想到应该先做些什么再做什么，而在实施过程又发现缺少相关的东西支持或与相关的东西存在冲突...，最后表面上能交出来，我相信他自己心里清楚内部是很混乱的（同事说：如果在这样继续下去，我会疯掉的）

这与思维方式有很大的关系，我们一般是先想后做，如果想是无序的，不全面的，矛盾的，做的结果也好不到那里去（即使在想->做的过程中还是有一个反馈的调整行为），

而抽象就是让你的思维方式以一种有序有的层次的方式进行问题（过程）的思考，告诉自己应该如何看待事物。

需要注意的是抽象做为一种主观的意识形态存在，也就是抽象是非形式的，从非形式到形式的过程中，受个人的主观意识影响很大：

         说个例子：在生活中，手机与小型计算器，在我们直观的看来很确定两样是不同的东西，为什么?因为在我们的潜意识上，已经对这两样东西按用途进行区分了，假设把这两样东西放在几百年前的古人面前，他们极有可能认为这两样东西是类似的东西，因为外型类似，又如，做为一个物品管理员，他有可能把这两样放在一起存放，因为他不是按用途进行分类的而按电子产品分类的。在开发中，这样的事常有发生，对同一个问题：一个说true , 一个说false ，如果你站在他们各自的上下文中看，都说的对。在面象对象语言中：继承，多态，封装，还有类型。。。 包括面象对象本身，这些都抽象的形式化产物(更高级的抽象)，而程序设计原则，极限(敏捷)开发过程，中有很多都与抽象密不分的关系存在。（这里，我想留给后面的高人进行分析讲解，这里就不多说）

例：抽象卖场中的商品(卖场：之前想用超市，觉得针对性太强，意思：是销售商品的场所，如：超市，小商店，临时贩卖档,,,任何形式的售卖点的统称)

在卖场中有对所有商品进行分类，如家电，服装，日用品。。。，而家电又分为电视，冰箱。。。　而电视又按厂家或尺寸分类，

分析：上面是抽象后的结果，是何如得到这些结果的；

在分析初期，我们假设我们对行业，厂家等的概念一无所知， (我们刚开启一个项目时，也是如此)，只知道卖场要把这些商品出售给消费者，但前提是能让消费都快速的找到它想要的商品；

假设设每个商品共有的属性：名称，型号，重量，颜色，尺寸，生产日期；而这些属性可能是我们根据实际中得到的资料（初步认知），

后来发现有一些商品的属性可能参差不齐，如：有些商品没有型号，反而额外的出现新的属性，但我们发现所有商品中都有一个“名称”的属性，

而这个名称的值(如：电视机)在很多商品中经常的出现，然后我们去追索这些最终的供应商(厂家)，

发现这些生产电视机厂家所提供的此类商品的属性极其的接近，以此类推其它的商品，也发现类同的情况，（发现case过程）；

这时我们可以定义原子概念：行业(电器，五金，家具，服装…)。

我们在回过来看卖场的要求：让消费者＊快速找到＊商品；由此，我们延伸出几个问题：

# 商品是什么?

这个问题我想通过上述的分析我们已有一个初步的概念：行业，以此方法可向下得出新的分支概念(电器->电视->32寸，40寸…或平板，背投)

# 如何才能快速?

通过分析商品，掌握了商品的抽象方法概念，可能还需要一些算法或其它理论支持，我们是有可能找到一个合适的“快速找”的方案

# 消费者是什么?

最后这个问题的答案是用来验证我们之前的抽象的结果是否“正确”(在开发中没有100%的正确，它是一个理解值，所以我们这里的“正确”是相对来说的)，前两个问题最终是为第三个问题而服务的，而卖场是面向消费者的服务单位，我想只有从卖场那里才能给出答案：白领，家庭主妇...。

 

B。建模

我们经常在开发过程中听到或看到，对数据库建模(建表建关系...)，对象建模(定义类型，定义class)，常看到一些人，在书上看到一些简单建模的例子，然后不管理是什么项目都死搬硬套用到该开发中去...（无话可说）。建模的意思其实也对某事物或过程进行抽象后的形式化的表现，也就是构造抽象的模型(模型有很多种表现手法，如图形，代码，表格...)。

根据上面的抽象分析，下面给出伪代码：

//我们抽象出来最基础的,表示所有的商品所共有的属性

Class MerchandiseBase //抽象

｛

       名称；型号；产地，生产日期　；

       ShowInfo(  ) ；

｝

//电器类的商品共有的属性

Class Wiring　：MerchandiseBase  //抽象

｛

       节能等级， 保修期， 是否三包 …

       ShowInfo(  ) ；

｝

//假设把电器类分为电视与手机下两种类别

Class TV：Wiring　//实现

｛

       类别（平板或背投），音频系统，视频格式…

      ShowInfo（）{  //实现抽象 }；

 

｝

Class Mobile：Wiring　//实现

｛

       来电功能，电话簿容量，待机时间，FM调频收音机...

        ShowInfo（）{  //实现抽象 }；

｝

虽然给出来的结果非常简单，但目的在于说明抽象思维运用，而在实际的开发中，远不止这样简单，需要分解成多个可处理的单位

最后：

抽象的概念的形成并非一日之功的事，我经常遇到一些做了四五年编程的人，他们对某语言可以说无所不知，但抽象的能力却不敢苟同；也许抽象不好掌握，但如果保持天天向上，好好学习的精神，也并非难事。设计一个良好的程序或系统，单是能理解抽象我觉得还远远不够，但总是一个好的开始。