2、面向接口_什么是面向接口

上篇谈了10大好处，大家肯定都问，什么是面向接口？这个概念有点大，我又不是什么专家，不能给这么大的一个概念去定义什么的，所以以下的是自己的理解，希望呢大家积极给我指正，让我在面向接口这个概念上有了新的认识，开始

• 我这里所指的面向接口是个泛指，它不光包括面向接口的编程，还包括其他领域，那么如果我只说概念的话又比较生涩，所以我要从一个项目说起，cms一个喜闻乐见的项目。大家都非常熟悉，我觉得这样大家会比较容易理解
• 等等，你不是要讲面向接口的概念吗？怎么说起项目了，我觉得直接说概念太难理解了，所以我会先描述一下我对这个项目的想法，然后把概念穿插在其中，最后再做个总结会比较合适，对吗
• 首先呢事先声明我从来没有做过这个项目，基础为0（哈哈，只知道基础），但是我有强大的工具支持：面向对象、uml（理论和rose）、面向接口
• 说一下想法：我需要应用uml的分析方法，从业务层入手------〉过度到概念层------〉最后是系统层，那么呢，每一层都试图用接口的分析方法试试，看看接口到底能做什么，既然我说面向接口无处不在，那么它将贯穿在业务层、概念层和系统层这里引用了咖啡哥的图作为说明，当然具体系统设计层是否用java框架那就再说了这里只是拿出说明一下，所以这里提到了面向接口的其中一点概念就是可以穿插在各层中
• 既然不了解cms是什么系统，那么就要从业务端入手，去进行分析，那么接口呢，是在业务模型中存在，还是在业务模型和概念模型的中间存在呢，事实上都可以存在，也可以都不存在，所以说面向接口很灵活
• 还是业务模型做例子，传统uml分析从受众和usercase入手，靠画活动图、usercase、时序图、状态图等来去分析，那么接口在哪里呢？接口就在这些图中间，换句话说就是一组图就可以表示了，具体等我详细分析这个cms业务模型时再讨论
• 还有一个问题是传统uml分析需要面向对象的分析方法，就是不用uml分析那也可能是面向过程，面向接口是新的方法吗？是第三种吗？答案是否定的，小弟认为面向接口属于实现方法，它本身并不影响面向对象或是面向过程，换句话说它只不过是一个面向对象（过程）的实现方法，为什么这么说呢？继续看
• 接口如何定义呢，大家想一下，首先，它有吃的东西，也就是传统意义的接收项，再说的明白一点就是前置条件。它还有什么，可能还有一个输出项，或是没有。那么我问了，它有驱使者吗？没有！那么它关注实现了吗？也没有。那么它如何来去描述一个user case或是一个活动图呢，显然不能，所以我说用面向接口来分析业务模型不可以，但面向对象就行，面向接口只是实现方式，这是它的又一个特性
• 还是拿业务模型做例子，假设我是一个产品经理来用uml分析业务，如果我分析的不好怎么办，其实我不是一个产品经理，所以我肯定分析不太好，但是我敢大胆的去分析，不是我胆子大啊，是因为我有利器在手，今天哪怕是错误的模型也不会有太多问题，因为接口的特性认为，只要接口订立后都不会再改变了（被用的情况下），如果它是错误的，大不了我不用了，从新再加个新接口，所以也就不会有太多的耦合存在于业务分析端，换句话说我只要不断将对业务新的理解加上就行，无需去太多的关注是否会有问题，而使我不敢去分析，不知道我说明白了没有，不明白没事，后面我们具体分析时就知道了
  
• 对于概念和系统设计也是如此，那么您要问我了，如此分析好麻烦啊，本身uml分析就很繁琐，你又每层加接口，你这是要搞那般？这里我要指出的是，uml分析不是做体操，无需每一节都如是做，各种图是帮助分析的，你可以没有啊，另外接口也是帮助分析的，你更可以没有啊，我们不能死板不是，实践证明你用了会更快速，而且有文字图形为证，铁证如山，只能说谁用谁知道啦

其实像上面的例子有很多，但仍然不能使我准确的把它的定义说出来，万恶的语文啊，当年没学好，不过没关系，在下一节的面向接口讨论中我将从这个实际的cms例子中来去展示一下如何让一个2流的产品经理去用uml方式运用面向对象的分析方法，实现确是接口的方法来搞定这个的，有点绕，有点好玩