关于面对对对象之接口的通俗理解

摘要: 一些人写代码，按照计算机思考的那个模式写，写出来的代码，能实现功能，但是拓展性不好，而有些人写代码，是按照人看世界的那些思路去写，写出来的代码 看起来像那么回事儿，而且也非常的符合逻辑，这是为什么？为什么同样是写代码，为什么写出来的东西会完全不一样了？

一些人写代码，按照计算机思考的那个模式写，写出来的代码，能实现功能，但是拓展性不好，而有些人写代码，是按照人看世界的那些思路去写，写出来的代码 看起来像那么回事儿，而且也非常的符合逻辑，这是为什么？为什么同样是写代码，为什么写出来的东西会完全不一样了？

最近一直在反思自己写的代码，以前写，都是为了完成某项功能而写，写完了也就完事儿了，可是最近却不是这样了，最近想打问题是，写代码是不是只要在实现功能的层面上就可以了了？后来得出的答案是，代码其实还可以写的更加的灵活多变一点的

那么今天我们就来谈谈关于这个写代码的技巧性的东西，我们经常在一些场合里面去使用面对对象的思想去编程，可是，在我真正的工作经验中所看到的却往往不是这样，他们很多的时候是打着面对对象的幌子却从事着面对过程编程的勾当。

我们来假设一下我们现在的一些个情景，很多人经常编写那种基于用户角色的管理系统，比如会员管理系统中的积分计算方式，比如A级别的会员，购买了B商品，他此时可以得到积分为C的相应积分，而B级别的会员，购买了B商品，他此时的到的积分为C+3的积分，那么我是试想一下，我么应该如何编写这种积分编写的规则了？

试想 我们如果使用我们最常见的那种方式，我们80%的情况下我们可能会这样写？

//伪代码
if(level==A){
count(C);//计算A级别会员积分
}
if(level==B){
count(+3)://计算B级别会员积分
}

按照以上的这种方式，随着等级增加，这样的判断类型会越来越多，这样的直接结果就是导致我们需要维护的文件会越来越多，代码也会越来越臃肿。最后代码就直接腐烂变质了

那么，另外的一种写法是怎么样了？

//伪代码
public interface IMember(){

public double count(double value);
}

public class Amember implements IMember(){
public double count(double value){

value = value+C;
return value;
}

public class BMember impelents IMember(){

public double count(double value){

value = value+C+3;
return value;
}
}

然后 我们只要根据登录的不同会员信息去产生不同的对象实例，调用同样的一个计算方式就好了。那么 这样 我们只需要在增加类的时候去添加对应的等级Member对象就可以了，这样我们就成功的将代码分开放置在了不同的类文件中，这样的话能够以最小的更改代价而完成最新的需求变更。

其实我想要表达的意思就是，如果想要用好面对对象的这个思维去编写程序，那么其实我们是有标准可以参照的。今天先只说一部分，以后再慢慢更。

首先要明白接口的使用，这个是面对对象当中最最最最重要的东西，没有之一。关于接口的书面描述，我就不想再多说了，各种参考书中都放置了相当多的描述，现在我主要是想说我对这个接口的理解和一些常见的疑惑问题解答。

1、在设计编码的书中中常常说起，要记住面对对抽象编程，而不是面对对具体实现编程？为什么

其实答案很简单，但是要想明白可能不是那么容易，我试着用最简单的方式去告诉你们怎么回事，接口当中，我们常常会写一些方法对吧。而且这些方法往往是没有任何实现的对吧？那么，那些数据中所说的面对抽象编程，其实就是指这个没有实现的方法编程。为什么？因为接口中定义的方法，他一定是抽象的 尽管你没有显示的说明他是抽象的，可是事实却是如此的。

而且，这些抽象的方法映射到我们的实际开发当中来说，这些个方式是一群对象所同时具有的一些个动作，只是具体的实现不同而已，这样一说，你是不是就能够很好的明白了这个接口到底什么什么玩意，可以用来做什么？ 面对对象的面对抽象编程就是这么个道理和内涵。

其实你可以发现好多设计精良的架构设计，你会发现里面有一堆的接口，然后有很多的类结构会去实现这样的接口，从而使得自己能够拥有一些个能够供自己使用的方法，所以在此我推荐的是，所有类中除了类本身所有用的一些类似于辅助的方法之外，其他的方法最好全部放到各个接口当中去实现最好，因为这样维护的成为最低，修改的代码成本最小。

其实很多人在编写代码之前的时候会时刻提醒自己 我们不能按照面对过程的方式来编写代码，但是一旦项目开动了，这些基本都不靠谱了。为什么了，因为他脑子里的潜意识永远没有去想，我这个方法到底是从哪儿来的？所以我给大家提的建议是思考如下三个问题，在你编写一个类的时候！

1、我的类是JAVABean么？这个里面除了getter,setter方法之外，其他的不要放

2、我的类中的方法是从某个接口中实现而来的么？不过建议先思考这样的问题在决定你的方法的来源，这样会更加省事儿的，血的教训

3、停顿60秒，然后再问自己以上的这两个问题

说一千到一万，其实接口就解决了一个问题，那就是很多动作的共性问题，简单点就是说，A有呼喊的技能，B也有呼喊的技能，不过A只会呼喊A语言，B会呼喊B语言的，那么假如我们使用了接口，则自动的屏蔽了具体的实现。这样就到达了多态（也就是对象实例为A时，A开始呼喊，对象实例为B时，B还是呼喊）。

在直白一点我们可以这样理解，接口其实就是一个领导，他只能在哪儿交换，从来不会去管下面如何实现的，他只要结果，所以，实现接口的类就像是领导直接管辖的下属，你只要按照他的大方向去做，然后告诉领导结果就够了。具体你怎么去做，就i自己想去吧...领导从来不会问你技术细节，因为他有自己有自己的宏（SHA）伟(BI)蓝(YI)图(GE)

啰嗦几句，编程需要技巧和思维，不过在这里在澄清一个误区，那就是业界流传着一句话说“多写多练”你就能成为大牛？我谢谢你，代码多写多看，而不去多想，你永远就是一个熟练工，一个CODER，而不是DEVELOPER好么。所以奉劝各位看到此文章的博友们，谨记着一句话，“多写多练变大牛”是有前提条件的好么，一定是要在“多想多总结”的基础上完成！！任何的语句有意义都是会有上下文语境的，这就是设计的哲学。