求一个用接口后和不用接口的好处

求一个用接口后和不用接口的好处一直不明白接口好像多余一样希望高手指点一下弄个简单例子对比一样用接口和不用接口案例对比一下

解决方案 »

  1.   

    什么是单一入口应用程序？在解释什么是单一入口应用程序之前，我们先来看看传统的 web 应用程序。
    news.php 显示新闻列表
    news_edit.php 显示新闻编辑页面
    这两个页面不但分别实现了两个功能，还成为了应用程序的两个入口。那什么是入口啊？
    打个比方，大家上 WC，都是男生进一个门，女生进一个门。这两个门就是 WC 的两个入口。呵呵，上面的例子应该很好理解吧。那稍微变换一下，单一入口的概念就很容易理解了。
    现在我们是进一个公共 WC，不管男女都是从最外面的入口进入，交了钱以后才分别进两个门。那最外面的入口就是这个 WC 的单一入口。所以单一入口的应用程序实际上就是说用一个文件处理所有的 HTTP 请求。例如不管是新闻列表功能还是新闻编辑功能，都是从浏览器访问 index.php 文件。这个 index.php 文件就是这个应用程序的单一入口。
    index.php 如何知道用户是要使用哪一个功能呢？很简单，我们访问 index.php 时跟上一个特定的参数就行了。例如 index.php?action=news 就是显示新闻列表，而 index.php?action=news_edit 就是新闻编辑。而在 index.php 里面，仅用两行代码就可以实现这种效果。
    <?php
    $action = $_GET['action'] == '' ? 'index' : $_GET['action'];
    include('files/' . $action . '.php');
    ?>上面的代码中，第一行是从 url 中取出 action 参数。如果没有提供 action 参数，就设置一个默认的 'index' 作为参数。
    第二行代码就是根据 $action 参数调用不同的代码文件，从而实现单一入口对应不同功能的效果。
    单一入口应用程序的入口文件很复杂？有些朋友可能以为单一入口程序的 index.php 会像面条一样复杂，其实是误解。
    例如我现在的应用程序入口文件只有下面几行：
    <?php
    define('APP',       realpath('../libs/website'));
    define('LANG',      'gb2312');
    define('DEBUG',     1);require('../libs/flea1/basic.php');
    run();
    ?>
    足够简单了吧？当然了，在 index.php 里面写上一长串 switch case 绝对是拙劣的实现方式。但这纯粹是开发者自己的设计和实现问题，而不是单一入口应用程序这种设计思想的问题。补充说明： 这里提到 switch case 并不是说用了 switch 就代表“落后”、“土气”等。只是说在 index.php 这个入口程序里面写上一堆 switch case 不利于程序的修改和维护，所以是一种不好的用法。
    单一入口应用程序的设计思想当web服务器（apache或者iis）收到一个http请求时，会解析该请求，确定要访问哪一个文件。例如 http://www.xxx.com/news.php 的解析结果就是要求web服务器解析 news.php 文件，并返回结果给浏览器。现在看看单一入口应用程序的 index.php 文件，就会发现 index.php 实际上根据 url 参数进行了第二次解析。完成这个解析的程序一般称为 Dispatcher（中文的准确翻译我也不知道），大概意思就是将不同的请求转发到不同的处理程序进行处理。在单一入口应用程序中，index.php 和 web服务器一起构成了一个 Dispatcher，根据 http 请求和 url 参数来确定请求的处理程序。了解了 Dispatcher 的概念后，我们可以发现前面提到的两行代码实际上就是一个最简单的 Dispatcher 实现：
    <?php
    $action = $_GET['action'] == '' ? 'index' : $_GET['action'];
    include('files/' . $action . '.php');
    ?>诚然，对于一个安全、健壮的应用程序，Dispatcher 肯定不是上面那么简单。在调用实际代码前，还会加上各种判断、安全性检查等。例如判断 url 指定的功能是否可以访问以及 url 中包含了无效的参数。看到这里，朋友们肯定会说：单一入口程序就多了就这样一个 dispatcher ，和我直接做成 news.php、news_edit.php 等单个文件相比有什么好处啊？
    单一入口应用程序的优势单一入口应用程序的所有http请求都是通过 index.php 接收并转发到功能代码去的，所以我们在 index.php 里面就能完成许多实际工作。这里我只拿安全性检查为例详细说明一下：
    由于所有的 http 请求都由 index.php 接收，所以可以进行集中的安全性检查。如果不是单一入口，那么开发者就必须记得在每一个文件的开始加上安全性检查代码（当然，安全性检查代码可以写到另一个文件中，只需要include进来就可以了）。
    但我想大家都是懒人，也许记性也不好，难免有忘记的时候。因此要记得在每一个文件前面都加上必要的include可不是件容易做到的事情。与安全性检查类似。在入口里，我们还可以对url参数和post进行必要的检查和特殊字符过滤、记录日志、访问统计等等各种可以集中处理的任务。“咦，搞这么多功能，不是会把 index.php 搞得很复杂吗？”
    “不会的。只需要把各种功能写到单独的文件，然后在index.php里面include进来就可以了！”可以看出，由于这些工作都被集中到了 index.php 来完成，可以减轻我们维护其他功能代码的难度。例如在10个文件中保持头部的几个include都一致可不是件让人愉快的事情。
    单一入口应用程序的缺点任何事情都有两面性，单一入口应用程序也不例外。由于所有 http 请求都是针对 index.php，所以应用程序的 url 看起来确实不那么美观。特别是对搜索引擎来说很不友好。要解决这个问题，可以采用 url 重写、PATHINFO 等方式。但我个人更推荐在前台页面不使用单一入口方式，而是保持多个文件入口。或者两者混用。例如新闻列表采用单独的 news.php 显示，而用户注册、发表信息等则采用单一入口。因为对于网站拥有者来说，新闻列表、新闻显示页面才是需要搜索引擎关注的高价值目标，而用户注册页面等交互性功能则根本没有收录的价值。有朋友提到单一入口的应用程序会有很长一串参数，那么我们分析一下下面这个 url：
    index.php?url=news&news_id=123&page=2&sort=title
    如果改为直接访问 news.php，也只不过省掉了 url=news 这一个参数而已。所以认为单一入口的应用程序 url 太复杂是没有道理的。
    如何组织单一入口应用程序的功能代码？单一入口应用程序最大的挑战来自于如何合理组织各个功能的处理代码。但只要遵循一定的步骤，也可以轻松的解决掉这个难题。首先，对于应用程序的功能要做出一个合理的分解。例如后台的新闻栏目可能包含“添加新闻”、“编辑新闻”、“删除新闻”等多个功能。这时我们就可以将这一组逻辑上关联的功能组合到一个功能模块中，称为“新闻管理”模块。
    按照上面的方法整理完应用程序的功能，我们就会得到多个功能模块，而每个模块又是由多个功能组成。（实际上，即便不是单一入口应用程序，功能的整理也是必须的步骤。）整理完功能后，我们就需要确定如何存放各个功能的代码。这里我推荐两种方式：1、每个功能模块一个子目录，目录里的每一个文件就是一个功能的实现代码。
    这种方式的好处是每个功能的代码都互相隔离，非常便于多人协作。缺点是每个功能之间共享代码和数据不那么方便。例如新闻管理模块中的所有功能都需要一个“取出新闻栏目记录”的功能，那么采用这种多个独立文件的组织方式，“取出新闻栏目记录”就只能写在另一个文件中，然后由需要该功能的文件include进去。2、每个模块一个文件，模块中的每个功能写成一个函数或者一个类方法。
    好处不用多说了，非常便于共享代码和数据。缺点就是如果几个人同时改，容易发生冲突。不过借助版本控制软件和差异比较合并工具，冲突还是很容易解决的。
    好了，我们的功能代码都确定存放方式了。那么如何调用呢？
    index.php 如何调用功能代码？调用首先就是要设计一个规则，然后让 index.php 根据这个规则来搜索和调用功能代码。就我自己来说，我总是使用 $_GET['url'] 来指定要调用的功能模块，而 $_GET['action'] 来指定该模块的特定功能。因此我的应用程序会使用如下的 url 地址：
    index.php?url=news&action=edit觉得两个参数太多了？那可以使用 index.php?func=news.edit 这样的 url。只需要将 news.edit 拆开为 news 和 edit 就行了。“嘿嘿，那我故意搞一个 index.php?url=news&action=xxx，看你的应用程序还能运行？”
    很显然，这样的 url 只会使得 index.php 无法找到需要的功能代码，最后报告错误。但是这和你在浏览器中访问 newsxxx.php 这个并不存在的文件有什么本质区别呢？相反，我还可以让 index.php 在发现找不到需要的功能代码时显示一个漂亮的出错页面，并提供一个返回网站首页的连接。在实际开发中，我倾向于将一些基本服务从应用程序中抽取出来，形成一个应用程序框架。这个框架通常会包含一个 Dispatcher、基本的数据库访问服务、模版引擎、常用的辅助功能等。由于有了一个框架，所以我可以更加让 Dispatcher 更加灵活。例如可以对某些功能模块应用权限检查，而另一些则不检查。
    进一步了解单一入口应用程序要深刻理解一个事物，自己尝试一下是最好的办法。你可以选择自己实现一个 Dispatcher 以及相应的各种规则，或者选择一个现有的应用程序框架。但更好的方式还是首先尝试一下现有的框架，然后再自己尝试实现一个类似的。这样可以在最短的时间内获得最多的收获。目前绝大多数 php 应用程序框架都是单一入口的，并采用了 MVC 模式（很遗憾，由于 MVC 实在太复杂，并且和单一入口应用程序也没有必然联系，所以我就不赘述了。感兴趣的朋友可以 google 一下相关资料）。我个人推荐下面的框架：FleaPHP
    http://www.fleaphp.org/
    嗯，我在做广告。因为这个框架是我做的。但我相信这个框架将是一个非常容易上手（就算不是最容易的）框架。
    全中文的代码注释、简单的结构、精简的代码都是 FleaPHP 框架的优势。
    CakePHP
    http://www.cakephp.org/
    一个 Ruby on Rails 的 PHP 仿制品。具有出色的功能，但显然太过于复杂，而且缺乏中文资料是个很大的问题。
    symfony
    http://www.symfony-project.com/
    一个超复杂的框架，集成了 n 多东西。项目网站上提供的视频演示看上去很不错。
    其他
    还有 Mojavi、Phing 等许多 PHP 框架，如果你精力充沛，可以去探索一下。
      

  2.   

    典型的例子，就是 订阅者模式消息发布者 怎么能每次发布消息，都能正确 发到 订阅者手上呢，因为
    首先有一个接口，比如叫 interface a{}，其有一个空方法 比如 function a_xyz();
    之后，订阅者们 全要实现这一接口，也就是把空方法 a_xyz();自己填充满
    之后，发布者 每次只要执行
    $订阅者1->a_xyz('新消息');
    $订阅者2->a_xyz('新消息');
    ……
    这样遍历一下就可以了如果没有这个接口 a{}和里面的 空方法 function a_xyz();会怎么样呢？从代码层次看，由于没有规范每个订阅者，一定要实现 a_xyz()方法，那么发布者只能这样执行
    $订阅者1->ab1('新消息');
    $订阅者2->c2de('新消息');
    $订阅者3->fgk('新消息');
    ……
    完全无规则的，调用各个订阅者的，不同方法，
    这太困难了，这要求 发布者，必须 知道 那么多订阅者不同的方法名，这是匪夷所思的
    所以在代码层次看，接口的作用，就是需要知道方法名称从编程层次看，不使用接口，
    但是，我让每个$订阅者，在编码细节的时候，都具备同一方法，比如 function kkk()，然后，
    $订阅者1->kkk('新消息');
    $订阅者2->kkk('新消息');
    ……
    这样不行吗？
    行啊，但是，这种编程，是适合一个人，随心所欲的，不计效率，想到哪写到哪改到哪的方式
    不适合，多人，在规定时间，规定地点，按规范完成任务
    所以，在编程层次看，接口的作用，是一种规范/契约，要求每个编程的人遵守从设计层次看，不使用接口，
    请问，那么如何表达出来，上面这种设计模式呢？
    每一种设计模式，都是一个范式，抽象的范式，
    这些范式，都是把现实生活中的物件，以及物件间的关系，经过迭代梳理后，抽象出来的，也就是归纳总结
    这种总结到理论的东西，难道还要这样写
    $订阅者1->kkk('新消息');
    $订阅者2->kkk('新消息');
    ……
    奥，这好像就是说，所以每个订阅者吗，都需要有一个同样的方法名，这样子的话，好像就好一点，是不是这样啊
    这样来让人猜？
    所以，在设计层次看，接口的作用，是为了表达 抽象的设计抽象的设计有什么用，复用，和开闭原则
    复用有什么用，减少 设计的工作量阿
    开闭原则有什么用，在设计层次上，更好的维护升级
    所以，复用 和开闭原则，说的都是设计，而不是细节代码，
    这谁说的，给我拖出去打死为止……接口衍生出来各种各样设计，
    订阅者模式，也是典型的控制反转ioc，
    还有像面向切面设计，依赖注入设计，23种设计模式，都和接口/虚类相关最简单的，从最低层去理解，接口，就是需要知道一个名字，因为不知道名字，什么都干不了，
    但是，这个名字，不能是细节编码的时候，那时想出来的，
    必须是设计的时候，先定义好的，才能达到抽象，范式，才好去复用/维护升级 设计
      

  3.   

    类的继承，在纯粹的C++中是有多重继承的，但是，目前绝大多数的OO语言都摒弃了多重继承，而用单一继承。但是，多重继承还是有一些特性需要得以实施。接口在很大程度上是为了“模拟”多重继承而进行的。接口，简单的说就是告诉类，你应该做些什么，但是将具体如何做留给了类本身。而实现了同一接口的不同类，必然有一个相同的“接口”（从而提供相同种类的功能）。一个简单的例子是iterable。一个对象可以被“iterate”，那么我们肯定可以指望这个对象可以告诉我们：有多少个元素，并有一个方法从头到尾将元素输出（遍历）。这样的“功能性”的要求用接口来规范就非常合适。但是，针对不同的对象（数组、字典、列表、tuple、集合），其元素数量的确定以及遍历方法的实现都会因对象内部实现机制的不同而不同，因此具体怎么实现就交给了那个定义对象的类去做了。