RewriteRule ^index\.html$ index.php

原始 news/detail.php?id=2  伪静态  news/detail_2.html

RewriteRule ^news/detail_([0-9]{1,})\.html$ news/detail.php?id=$1

原始 index.php?cid=2&id=3  伪静态 2-3.html

RewriteRule ([a-zA-Z]{1,})-([0-9]{1,})\.html$ index.php?cid=$1&id=$2

([a-zA-Z]{1,})-([0-9]{1,})\.html$是规则，index.php?action=$1&id=$2是要替换的格式，$1代表第一个括号匹配的值，$2代表第二个，如此类推！！

引用

M是指model。Controller 并不参与业务逻辑，整个业务逻辑部分应该是放在 Model 层中的。Controller 只起到分发请求的作用，也就是说得到当前的 Request，决定调用哪个 Model 获取数据，然后再赋值给哪个 View 来渲染页面

具体实现MVC，我觉得最好还是要做到单点入口。
什么是单点入口呢？所谓单点入口就是整个应用程序只有一个入口，所有的实现都通过这个入口来转发，比如说在上面我们就使用index.php作为程序的单点入口，当然这个是可以由你自己任意控制的。
为什么要做到单点入口呢？单点入口有几大好处：第一、一些系统全局处理的变量，类，方法都可以在这里进行处理。比如说你要对数据进行初步的过滤，你要模拟session处理，你要定义一些全局变量，甚至你要注册一些对象或者变量到注册器里面（主要是实现在全局，具体你可以参考我先前翻译的一些文章《在PHP中使用全局变量》）。第二、程序的架构更加清晰明了。当然好处还有很多的，我也不一一列举了，具体你可以去体会。
当然单点入口也存在一些不足，比如你系统大了后，不可能只一个点做为入口，尤其系统存在两个完全不相关的功能时候，不过很高兴的说，这个是可以扩展，你可以扩展多个入口。比如说在最近一个大项目中，后台的管理和前台是不相关的，所以我就会有两个入口，一个是index.php一个是admin.php。但这不不是说单点入口不好（具体含义你可以揣摩下）。
那么，如何实现单点入口呢？这是我本节的重点。一般来说都是通过url的地址映射实现的（前面我有一篇文章说到这个：《回答PHPCHINA上的几个问题:URL映射》，里面实现了单点入口的核心，这里我具体实现，并演示下）。单点入口最关键的就是通过url传递参数来实现程序的分配，具体说，比如：地址是index.php?controller=test&action=test，这就通过index.php把请求转发到对应的testController文件中，并执行其对应的testAction方法（这里的控制器和方法的命名都参考了Zend Framework的思想）。
下面我们用最简单的方法是来实现上面说的单点入口（记住：简单起见，我这里没有使用URL映射了）
/index.php
<?
/**
* MVC演示demo
* 仅仅实现最基本的MVC功能，不包含安全处理，数据过滤，及其他优化措施。
*/
define(‘SITE_PATH’,str_replace(”,’/',dirname(__FILE__)));//定义系统目录

$controller=(!empty($_GET['controller']))?$_GET['controller']:’index’;//获取控制器,默认index
$action=(!empty($_GET['action']))?$_GET['action']:’index’;//方法名称，默认index

$controller_name=$controller.’Controller’;
$controller_file=SITE_PATH.’/app/controller/’.$controller_name.’.class.php’;//获取控制器文件
if(file_exists($controller_file)){
require_once($controller_file);
$controller=new $controller_name();
$controller->{$action.’Action’}();
}else{
die(‘找不到对应的控制器！’);
}
?>

对应的一个演示demo
/app/controller/testController.class.php（注意路径）
<?
/**
* MVC演示demo
* 仅仅实现最基本的MVC功能，不包含安全处理，数据过滤，及其他优化措施。
*/
class testController
{
function testAction(){
echo ‘Hello,World!’;
}
}
?>

打开浏览器，输入http://path/to/yoursite/index.php?controller=test&action=test（注意相应的修改你的路径），如果你看到Hello,World!说明MVC第一步，单点入口成功了！

在解释什么是单一入口应用程序之前，我们先来看看传统的 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 一下相关资料）。

继充满激情的牧羊座之后，是不轻易浪费自己能量的金牛座。金牛座的人不愿意毫无意义地说教，无缘无故地行动和失去理智激动。你不放任激情，也没 有紧迫感，这是一个强烈抑制精神和思想总是按一定尺度运行的人。如果出生时刻的天宫图中有较强的金牛座的影响，那么你会有良好的自卫本能。从积极的意义上看，你的性格平稳、有毅力和耐力，勤劳智慧，富有实干精神。为人处世小心谨慎，感情真诚专一。此外，你有极其敏锐的感官，内心怀 有各种欲望。喜欢舒适的生活环境，大自然的壮丽景色、花草和动物。

金牛座的人是一个喜欢按自己的人生哲学走路的人。你不轻易改变自己的生活习惯。固执已见是你性格上的突出特点，同时也是你的主要缺点。平时温文 尔雅，一旦受到触怒，你会变得令人望而生畏。金牛座的人家庭观念较强，你把家庭天地作为寄托自己幸福和安居乐业生活的可靠圣殿。你爱孩子胜过一切，并对你 们寄予厚望。

这一座的人对逆境的适应较慢。挫折和失败常能使你意志消沉，甚至你会人为地把自己囚禁在无声的愤怒之中，拒绝与外界的一切接触。一旦境况有所好 转，你又会重新振作起来，以空前的工作热情去实现自己的目标。金牛座的人思想趋于保守，但善于理财。当你拥有一定数量的财产，手头从不短缺时，你方能感到 坦然自若。经济上，你的现实感非常强，十分善于安排自己的物质和家庭生活。事业上，你也是强者，具有天生的无懈可击的才华。你的成功之路往往是漫长的，但 又是确定无疑的，尤其在农业、建筑和商业等行业方面。

金牛座的男性

这是一个喜欢安定的生活和具有田园诗盘性格的人。感情节奏的变化比较缓慢，然而一经触发将会身不由已，无法自拔。稳定而持久的生活环境，对你至 关重要。你不喜欢素不相识或萍水相逢的人来扰乱你的生活。无论在爱情上，还是在物质上的追求，你都是以可靠和安全作为权衡的主要标准，这甚至是你性格和思 想的基础。

你既是一个多思多虑的人，又是一个不拒绝享乐的人。美味佳肴是你生活中必不可少的伴侣。

对待婚姻，金牛座的人首先考虑的是，这种结合是否对诸方都有利，喜欢根据对方的家境及其工作能力作为选择的主要条件。因为你需要的是一个既能承 担家庭生活的责任，又能帮你料理财政的妻子。你希望美好的爱情中充满佳肴的芳香。你十分欣赏能烧一手好菜的妻子。和谐的爱情生活是你们感情的基础，生理上 的平衡在你的生活中占有极其重要的地位。金牛座的人，对新生事物适应较慢，不愿意轻易改变自己的生活习惯。

家庭和孩子是你生活的中心，是你欢乐和自豪的资本。尤其孩子是你终生夙愿的寄托。

金牛座的人的性格比较平稳，很少发脾气。不过，一旦发作则非同小可，会使人毛骨悚然。

与生辰星位在天蝎座的女性会情投意合，但这两个个性很强的人又不常相逢。

与生辰星位在处女座或魔羯座的女性结为伴侣，生活会充实、和谐和友爱。因为这两个星座的女性在体贴丈夫、管理家务和照顾子女方面各有所长。

总而言之，金牛座的你：

注重现实的金牛座的人说：”我具有……”。

表达爱情的方式：忠心耿耿或不厌其烦。

是一个：感情丰富的人。

渴望：感情缠绵和擅长烹任的爱人。

受骗：当受到性爱吸引时。

喜欢：到农村和田野中去。

追求：具有可靠基础的一切。

弱点：自我意识过强。

有利条件：坚持不懈。

不利条件：不爱动。

假期生活：园艺和烹调。

开支：购买起居设备和娱乐用品。

吉祥物：圣甲虫像。

吉祥金属：铜。

吉祥宝石：珊瑚。

吉祥日：星期五。

吉祥数字：6、15、24、33。

喜欢的场所：田园生活、草坪、原野和牧场，银行和保险公司。

吉祥植物：牡丹、锦葵、报春、紫罗兰和野花。

居住条件：绝对舒适的环境，经久耐用的家具和现代化的厨房设备。

理想旅居国：爱尔兰、丹麦、澳大利亚和阿根廷。

但是，没有面向对象的语言构造，程序员仍然可以把 OO 特性引入到 PHP 代码中。这样做有点困难并且会使代码难于阅读，因为它是混合范例（含有伪 OO 设计的过程语言）。使用 PHP 代码中的 OO 构造 — 例如能够定义和使用类、能够构建使用继承的类之间的关系以及能够定义接口 — 可以更轻松地构建符合优秀 OO 实践的代码。

虽然没有过多模块化的纯过程设计运行得很好，但是 OO 设计的优点表现在维护上。由于典型应用程序的大部分生命周期都花费在维护上，因此代码维护是应用程序生命周期的重要部分。并且在开发过程中代码维护很容易 被遗忘。如果在应用程序开发和部署方面存在竞争，那么长期可维护性可能被放在比较次要的地位。

模块化 — 优秀 OO 设计的主要特性之一 — 可以帮助完成这样的维护。模块化将帮助封装更改，这样可以随着时间的推移更轻松地扩展和修改应用程序。

总的来说，虽然构建 OO 软件的习惯不止 7 个，但是遵循这里的 7 个习惯可以使代码符合基本 OO 设计标准。它们将为您提供更牢固的基础，在此基础之上建立更多 OO 习惯并构建可轻松维护与扩展的软件。这些习惯针对模块化的几个主要特性。有关独立于语言的 OO 设计优点的更多信息，请参阅 参考资料。

7 个优秀 PHP OO 习惯包括：

1. 保持谦虚。
2. 做个好邻居。
3. 避免看到美杜莎。
4. 利用最弱的链接。
5. 您是橡皮；我是胶水。
6. 限制传播。
7. 考虑使用模式。

保持谦虚

保持谦虚指避免在类实现和函数实现中暴露自己。隐藏您的信息是一项基本习惯。如果不能养成隐藏实现细节的习惯，那么将很难养成任何其他习惯。信息隐藏也称为封装。

直接公开公共字段是一个坏习惯的原因有很多，最重要的原因是让您在实现更改中没有应有的选择。使用 OO 概念隔离更改，而封装在确保所作更改在本质上不是病毒性（viral）更改方面扮演不可或缺的角色。病毒性 更改是开始时很小的更改 — 如将保存三个元素的数组更改为一个只包含两个元素的数组。突然，您发现需要更改越来越多的代码以适应本应十分微不足道的更改。

开始隐藏信息的一种简单方法是保持字段私有并且用公共访问方法公开这些字段，就像家中的窗户一样。并没有让整面墙都朝外部开放，而只打开一两扇窗户（我将在 “好习惯：使用公共访问方法” 中介绍访问方法的更多信息）。

除了允许您的实现隐藏在更改之后外，使用公共访问方法而非直接公开字段将允许您在基本实现的基础上进行构建，方法为覆盖访问方法的实现以执行略微不同于父方法的行为。它还允许您构建一个抽象实现，从而使实际实现委托给覆盖基本实现的类。

坏习惯：公开公共字段

在清单 1 的坏代码示例中，Person 对象的字段被直接公开为公共字段而非使用访问方法。虽然此行为十分诱人，尤其对于轻量级数据对象来说更是如此，但是它将对您提出限制。
清单 1. 公开公共字段的坏习惯

<?php
class Person
{
    public $prefix;
    public $givenName;
    public $familyName;
    public $suffix;
}

$person = new Person();
$person->prefix = "Mr.";
$person->givenName = "John";

echo($person->prefix);
echo($person->givenName);

?>

如果对象有任何更改，则使用该对象的所有代码也都需要更改。例如，如果某人的教名、姓氏和其他名字被封装到 PersonName 对象中，则需要修改所有代码以适应更改。

好习惯：使用公共访问方法

通过使用优秀的 OO 习惯（参见清单 2），同一个对象现在拥有私有字段而非公共字段，并且通过称为访问方法 的 get 和 set 公共方法谨慎地向外界公开私有字段。这些访问方法现在提供了一种从 PHP 类中获取信息的公共方法，这样在实现发生更改时，更改使用类的所有代码的需求很可能变小。
清单 2. 使用公共访问方法的好习惯

<?php
class Person
{
    private $prefix;
    private $givenName;
    private $familyName;
    private $suffix;

    public function setPrefix($prefix)
    {
        $this->prefix = $prefix;
    }

    public function getPrefix()
    {
        return $this->prefix;
    }

    public function setGivenName($gn)
    {
        $this->givenName = $gn;
    }

    public function getGivenName()
    {
        return $this->givenName;
    }

    public function setFamilyName($fn)
    {
        $this->familyName = $fn;
    }

    public function getFamilyName()
    {
        return $this->familyName;
    }

    public function setSuffix($suffix)
    {
        $this->suffix = $suffix;
    }

    public function getSuffix()
    {
        return $suffix;
    }

}

$person = new Person();
$person->setPrefix("Mr.");
$person->setGivenName("John");

echo($person->getPrefix());
echo($person->getGivenName());

?>

乍看之下，这段代码可能会完成大量工作，并且实际上可能更多是在前端的工作。但是，通常，使用优秀的 OO 习惯从长远来看十分划算，因为将极大地巩固未来更改。

在清单 3 中所示的代码版本中，我已经更改了内部实现以使用名称部件的关联数组。比较理想的情况是，我希望拥有错误处理并且更仔细地检查元素是否存在，但是本例的目 的在于展示使用我的类的代码无需更改的程度 — 代码并没有察觉到类发生更改。记住采用 OO 习惯的原因是要谨慎封装更改，这样代码将更具有可扩展性并且更容易维护。
清单 3. 使用不同内部实现的另一个示例

<?php
class Person
{
    private $personName = array();

    public function setPrefix($prefix)
    {
        $this->personName['prefix'] = $prefix;
    }

    public function getPrefix()
    {
        return $this->personName['prefix'];
    }

    public function setGivenName($gn)
    {
        $this->personName['givenName'] = $gn;
    }

    public function getGivenName()
    {
        return $this->personName['givenName'];
    }

    /* etc... */
}

/*
 * Even though the internal implementation changed, the code here stays exactly
 * the same. The change has been encapsulated only to the Person class.
 */
$person = new Person();
$person->setPrefix("Mr.");
$person->setGivenName("John");

echo($person->getPrefix());
echo($person->getGivenName());

?>

做个好邻居

在构建类时，它应当正确地处理自己的错误。如果该类不知道如何处理错误，则应当以其调用者理解的格式封装这些错误。此外，避免返回空对象或者状态无 效的对象。许多时候，只需通过检验参数并抛出特定异常说明提供参数无效的原因就可以实现这一点。在您养成这个习惯时，它可以帮您 — 和维护代码或使用对象的人员 — 节省很多时间。

坏习惯：不处理错误

考虑清单 4 中所示的示例，该示例将接受一些参数并返回填充了一些值的 Person 对象。但是，在 parsePersonName() 方法中，没有验证提供的 $val 变量是否为空、是否是零长度字符串或者字符串是否使用无法解析的格式。parsePersonName() 方法不返回 Person 对象，但是返回 null。使用这种方法的管理员或程序员可能会觉得很麻烦 — 至少他们现在需要开始设置断点并调试 PHP 脚本。
清单 4. 不抛出或处理错误的坏习惯

class PersonUtils
{
    public static function parsePersonName($format, $val)
    {
        if (strpos(",", $val) > 0) {
            $person = new Person();
            $parts = split(",", $val); // Assume the value is last, first
            $person->setGivenName($parts[1]);
            $person->setFamilyName($parts[0]);
        }
        return $person;
    }
}

清单 4 中的 parsePersonName() 方法可以修改为在 if 条件外部初始化 Person 对象，确保总是获得有效的 Person 对象。但是，您得到的是没有 set 属性的 Person，这仍然没有很好地改善您的困境。

好习惯：每个模块都处理自己的错误

不要让调用方凭空猜测，而是对参数进行预先验证。如果未设置的变量无法生成有效的结果，请检查变量并抛出 InvalidArgumentException。如果字符串不能为空或者必须为特定格式，请检查格式并抛出异常。清单 5 解释了如何在演示一些基本验证的 parsePerson() 方法中创建异常以及一些新条件。
清单 5. 抛出错误的好习惯

<?php
class InvalidPersonNameFormatException extends LogicException {}

class PersonUtils
{
    public static function parsePersonName($format, $val)
    {
        if (! $format) {
            throw new InvalidPersonNameFormatException("Invalid PersonName format.");
        }

        if ((! isset($val)) || strlen($val) == 0) {
            throw new InvalidArgumentException("Must supply a non-null value to parse.");
        }

    }
}
?>

最终目的是希望人们能够使用您的类，而不必了解其中的工作原理。如果他们使用的方法不正确或者不是按照期望的方法使用，也不需要猜测不能工作的原因。作为一个好邻居，您需要知道对您的类进行重用的人并没有特异功能，因此您需要解决猜测的问题。

避免看到美杜莎

在我最初了解 OO 概念时，我十分怀疑接口是否真正有帮助。我的同事给我打了个比方，说不使用接口就好像看到美杜莎的头。在希腊神话中，美杜莎是长着蛇发的女怪。凡是看了她 一眼的人都会变成石头。杀死美杜莎的珀尔休斯通过在盾上观察她的影子，避免了变成石头而得以与她对抗。

接口就是对付美杜莎的镜子。当您使用一个特定的具体实现时，代码也必须随着实现代码的更改而更改。直接使用实现将限制您的选择，因为您已经在本质上把类变成了 “石头”。

坏习惯：不使用接口

清单 6 显示了从数据库中装入 Person 对象的示例。它将获取人员的姓名并返回数据库中匹配的 Person 对象。
清单 6. 不使用接口的坏习惯

<?php
class DBPersonProvider
{
    public function getPerson($givenName, $familyName)
    {
        /* go to the database, get the person... */
        $person = new Person();
        $person->setPrefix("Mr.");
        $person->setGivenName("John");
        return $person;
    }
}

/* I need to get person data... */
$provider = new DBPersonProvider();
$person = $provider->getPerson("John", "Doe");

echo($person->getPrefix());
echo($person->getGivenName());

?>

在环境发生更改之前，从数据库中装入 Person 的代码都可以正常运行。例如，从数据库装入 Person 可能适用于第一个版本的应用程序，但是对于第二个版本，可能需要添加从 Web 服务装入人员的功能。其实，该类已经变成 “石头”，因为它在直接使用实现类并且现在能做的更改十分有限。

好习惯：使用接口

清单 7 显示了一个代码示例，在实现了加载用户的新方法后并没有进行更改。该示例显示了一个名为 PersonProvider 的接口，该接口将声明单个方法。如果任何代码使用 PersonProvider，代码都禁止直接使用实现类。相反，它就像是一个实际对象一样使用 PersonProvider。
清单 7. 使用接口的好习惯

<?php
interface PersonProvider
{
    public function getPerson($givenName, $familyName);
}

class DBPersonProvider implements PersonProvider
{
    public function getPerson($givenName, $familyName)
    {
        /* pretend to go to the database, get the person... */
        $person = new Person();
        $person->setPrefix("Mr.");
        $person->setGivenName("John");
        return $person;
    }
}

class PersonProviderFactory
{
    public static function createProvider($type)
    {
        if ($type == 'database')
        {
            return new DBPersonProvider();
        } else {
            return new NullProvider();
        }
    }
}

$config = 'database';
/* I need to get person data... */
$provider = PersonProviderFactory::createProvider($config);
$person = $provider->getPerson("John", "Doe");

echo($person->getPrefix());
echo($person->getGivenName());
?>

在使用接口时，尝试避免直接引用实现类。相反，使用对象外部的内容可以提供正确的实现。如果您的类将装入基于某些逻辑的实现，它仍然需要获取所有实现类的定义，并且那样做也无法取得任何效果。

您可以使用 Factory 模式来创建实现接口的实现类的实例。根据约定，factory 方法将以 create 为开头并返回接口。它可以为您的 factory 获取必要的参数以计算出应当返回哪个实现类。

在清单 7 中，createProvider() 方法只是获取 $type。如果 $type 被设为 database，工厂将返回 DBPersonProvider 的实例。从数据库中装入人员的任何新实现都不要求在使用工厂和接口的类中进行任何更改。DBPersonProvider 将实现 PersonProvider 接口并且拥有 getPerson() 方法的实际实现。

利用最弱的链接

将模块松散耦合 在一起是件好事情；它是允许您封装更改的属性之一。另外两个习惯 — “保持谨慎” 和 “避免看到美杜莎” — 可帮助您构建松散耦合的模块。要实现松散耦合的类，可通过养成降低类依赖关系的习惯实现。

坏习惯：紧密耦合

在清单 8 中，降低依赖关系并不是必须降低使用对象的客户机的依赖关系。相反，该示例将演示如何降低与正确类的依赖关系并最小化这种依赖关系。
清单 8. Address 中紧密耦合的坏习惯

<?php

require_once "./AddressFormatters.php";

class Address
{
    private $addressLine1;
    private $addressLine2;
    private $city;
    private $state; // or province...
    private $postalCode;
    private $country;

    public function setAddressLine1($line1)
    {
        $this->addressLine1 = $line1;
    }

		/* accessors, etc... */

    public function getCountry()
    {
        return $this->country;
    }

    public function format($type)
    {
        if ($type == "inline") {
            $formatter = new InlineAddressFormatter();
        } else if ($type == "multiline") {
            $formatter = new MultilineAddressFormatter();
        } else {
            $formatter = new NullAddressFormatter();
        }
        return $formatter->format($this->getAddressLine1(),
            $this->getAddressLine2(),
            $this->getCity(), $this->getState(), $this->getPostalCode(),
            $this->getCountry());
    }
}

$addr = new Address();
$addr->setAddressLine1("123 Any St.");
$addr->setAddressLine2("Ste 200");
$addr->setCity("Anytown");
$addr->setState("AY");
$addr->setPostalCode("55555-0000");
$addr->setCountry("US");

echo($addr->format("multiline"));
echo("n");

echo($addr->format("inline"));
echo("n");

?>

在 Address 对象上调用 format() 方法的代码可能看上去很棒 — 这段代码所做的是使用 Address 类，调用 format() 并完成。相反，Address 类就没那么幸运。它需要了解用于正确格式化的各种格式化方法，这可能使 Address 对象无法被其他人很好地重用，尤其是在其他人没有兴趣在 format() 方法中使用格式化方法类的情况下。虽然使用 Address 的代码没有许多依赖关系，但是 Address 类却有大量代码，而它可能只是一个简单的数据对象。

Address 类与知道如何格式化 Address 对象的实现类紧密耦合。

好习惯：在对象之间松散耦合

在构建优秀的 OO 设计时，必须考虑称为关注点分离（Separation of Concerns，SoC）的概念。SoC 指尝试通过真正关注的内容分离对象，从而降低耦合度。在最初的 Address 类中，它必须关注如何进行格式化。这可能不是优秀的设计。然而，Address 类应当考虑 Address 的各部分，而某种格式化方法应当关注如何正确格式化地址。

在清单 9 中，格式化地址的代码被移到接口、实现类和工厂中 — 养成 “使用接口” 的习惯。现在，AddressFormatUtils 类负责创建格式化方法并格式化 Address。任何其他对象现在都可以使用 Address 而不必担心要求获得格式化方法的定义。

清单 9. 在对象之间松散耦合的好习惯

<?php

interface AddressFormatter
{
    public function format($addressLine1, $addressLine2, $city, $state,
        $postalCode, $country);
}

class MultiLineAddressFormatter implements AddressFormatter
{
    public function format($addressLine1, $addressLine2, $city, $state,
        $postalCode, $country)
    {
        return sprintf("%sn%sn%s, %s %sn%s",
            $addressLine1, $addressLine2, $city, $state, $postalCode, $country);
    }
}

class InlineAddressFormatter implements AddressFormatter
{
    public function format($addressLine1, $addressLine2, $city, $state,
        $postalCode, $country)
    {
        return sprintf("%s %s, %s, %s %s %s",
            $addressLine1, $addressLine2, $city, $state, $postalCode, $country);
    }
}

class AddressFormatUtils
{
    public static function formatAddress($type, $address)
    {
        $formatter = AddressFormatUtils::createAddressFormatter($type);

        return $formatter->format($address->getAddressLine1(),
            $address->getAddressLine2(),
            $address->getCity(), $address->getState(),
            $address->getPostalCode(),
            $address->getCountry());
    }

    private static function createAddressFormatter($type)
    {
        if ($type == "inline") {
            $formatter = new InlineAddressFormatter();
        } else if ($type == "multiline") {
            $formatter = new MultilineAddressFormatter();
        } else {
            $formatter = new NullAddressFormatter();
        }
        return $formatter;
    }
}

$addr = new Address();
$addr->setAddressLine1("123 Any St.");
$addr->setAddressLine2("Ste 200");
$addr->setCity("Anytown");
$addr->setState("AY");
$addr->setPostalCode("55555-0000");
$addr->setCountry("US");

echo(AddressFormatUtils::formatAddress("multiline", $addr));
echo("n");

echo(AddressFormatUtils::formatAddress("inline", $addr));
echo("n");
?>

当然，缺点是只要使用模式，通常就意味着工件（类、文件）的数量会增加。但是，通过减少每个类中的维护可以弥补这个缺点，甚至在获得正确的可重用性时反而可以减少工件量。

您是橡皮；我是胶水

具有高度内聚力的 OO 设计被集中并组织到相关模块中。了解 “关注点” 对于决定如何紧密地联系函数和类十分重要。

坏习惯：降低内聚力

当设计的内聚力较低 时，它就不能良好地组织类和方法。意大利面条式代码（spaghetti code）一词通常用于描述捆绑在一起并且具有低内聚力的类和方法。清单 10 提供了意大利面条式代码的示例。相对通用的 Utils 类将使用许多不同对象并且有许多依赖关系。它执行很多操作，因而很难实现重用。
清单 10. 降低内聚力的坏习惯

<?php

class Utils
{
    public static function formatAddress($formatType, $address1,
        $address2, $city, $state)
    {
        return "some address string";
    }

    public static function formatPersonName($formatType, $givenName,
        $familyName)
    {
        return "some person name";
    }

    public static function parseAddress($formatType, $val)
    {
        // real implementation would set values, etc...
        return new Address();
    }

    public static function parseTelephoneNumber($formatType, $val)
    {
        // real implementation would set values, etc...
        return new TelephoneNumber();
    }
}

?>

好习惯：利用高内聚力

高内聚力 指将相互关联的类和方法分组在一起。如果方法和类都具有高度的内聚力，则可以轻松地分解整个组而不影响设计。具有高内聚力的设计将提供降低耦合的机会。清单 11 显示了被较好组织到类中的两个方法。AddressUtils 类将包含用于处理 Address 类的方法，显示了与地址相关的方法之间的高度内聚力。同样地，PersonUtils 将包含专门处理 Person 对象的方法。这两个拥有高度内聚力方法的新类的耦合性都很低，因为可以完全独立地使用。
清单 11. 高内聚力的好习惯

<?php

class AddressUtils
{
    public static function formatAddress($formatType, $address1,
        $address2, $city, $state)
    {
        return "some address string";
    }

    public static function parseAddress($formatType, $val)
    {
        // real implementation would set values, etc...
        return new Address();
    }

}

class PersonUtils
{
    public static function formatPersonName($formatType, $givenName,
        $familyName)
    {
        return "some person name";
    }

    public static function parsePersonName($formatType, $val)
    {
        // real implementation would set values, etc...
        return new PersonName();
    }
}

?>

限制传播

我经常对我所在的软件团队（我在其中担任技术主管或架构师）的成员提起，OO 语言最大的敌人是复制和粘贴操作。当在缺少预先 OO 设计的情况下使用时，没有任何操作会像在类之间复制代码那样具有破坏性。无论何时，如果想将代码从一个类复制到下一个类中，请停下来并考虑如何使用类层次 结构利用类似功能或相同功能。在大多数情况下，使用优秀设计后，您将会发现完全没有必要复制代码。

坏习惯：不使用类层次结构

清单 12 显示了部分类的简单示例。它们从重复的字段和方法开始 — 从长远来看，不利于应用程序作出更改。如果 Person 类中有缺陷，则 Employee 类中也很可能有一个缺陷，因为看上去似乎实现是在两个类之间复制的。
清单 12. 不使用层次结构的坏习惯

<?php
class Person
{
    private $givenName;
    private $familyName;
}

class Employee
{
    private $givenName;
    private $familyName;
}

?>

继承 是一个很难入手的习惯，因为构建正确继承模型的分析通常需要花费大量时间。反过来，使用 Ctrl+C 组合键和 Ctrl+V 组合键构建新实现只需几秒钟。但是省下的这部分时间通常会在维护阶段迅速抵销掉，因为应用程序实际上将花费大量进行维护。

好习惯：利用继承

在清单 13 中，新 Employee 类将扩展 Person 类。它现在将继承所有通用方法并且不重新实现这些方法。此外，清单 13 显示了抽象方法的用法，演示如何将基本功能放入基类中以及如何阻止实现类使用特定函数。
清单 13. 利用继承的好习惯

<?php
abstract class Person
{
    private $givenName;
    private $familyName;

    public function setGivenName($gn)
    {
        $this->givenName = $gn;
    }

    public function getGivenName()
    {
        return $this->givenName;
    }

    public function setFamilyName($fn)
    {
        $this->familyName = $fn;
    }

    public function getFamilyName()
    {
        return $this->familyName;
    }

    public function sayHello()
    {
        echo("Hello, I am ");
        $this->introduceSelf();
    }

    abstract public function introduceSelf();

}

class Employee extends Person
{
    private $role;

    public function setRole($r)
    {
        $this->role = $r;
    }

    public function getRole()
    {
        return $this->role;
    }

    public function introduceSelf()
    {
        echo($this->getRole() . " " . $this->getGivenName() . " " .
            $this->getFamilyName());
    }
}
?>

考虑使用模式

设计模式指对象和方法的常见交互，并且时间证明它可以解决某些问题。当您考虑使用设计模式时，您就需要了解类之间如何进行交互。它是构建类及其交互操作的简单方法，无需重蹈他人的覆辙，并从经过证明的设计中获益。

坏习惯：一次考虑一个对象

实际上没有适当的代码示例可以演示如何考虑使用模式（尽管有丰富的优秀示例可以显示模式实现）。但是，一般而言，您知道在满足以下条件时一次只能考虑一个对象：

• 不会提前设计对象模型。
• 开始编写单一方法的实现，而无需去掉大部分模型。
• 在交谈中不使用设计模式名而宁愿谈论实现。

好习惯：同时添加模式中形成的对象

一般而言，当您在执行以下操作时就是在考虑使用模式：

• 提前构建类及其交互操作。
• 根据模式套用类。
• 使用模式名，如 Factory、Singleton 和 Facade。
• 去掉大部分模型，然后开始添加实现。

结束语

在 PHP 中养成良好的 OO 习惯将帮助您构建更稳定、更易于维护和更易于扩展的应用程序。记住：

• 保持谨慎。
• 做个好邻居。
• 避免看到美杜莎。
• 利用最弱的链接。
• 您是橡皮，我是胶水。
• 限制传播。
• 考虑使用模式。

当您养成并应用这些习惯后，您很可能会惊讶地发现应用程序在质量上的飞跃。

如果你希望成为一个成功的产品经理，在遇到bug时，请不要总是立即着急的修复它。不可否认，我们在遇到问题时，总是迫不及待的想改正。然而事实上，其实根本不用那么的十万火急，理由如下：

如果迅速解决了问题，你可能会忽略问题的根本原因。在大多数时候，每个问题都有其根本诱因。在问题刚暴露的时候，诱因一般深藏不露，有很多的可能性。笔者认为，根本诱因最可能来自于需求确认阶段。

同 样，在产品管理的其他阶段，这个理论也适用。有些问题可以很容易就找到根本诱因，但产品开发的真正挑战来自各种不稳定的因素。例如，有时候一款漏洞百出的 产品在上线之初，只暴露了冰山一角：一个很小的Bug，似乎十分容易解决。另一个例子，开发过程中，团队成员对各项功能的优先级有争议时，靠“民主投票” 来做决策，而忘了引发争议的源头：对产品远景、战略及计划缺乏共识。

医生治疗的是疾病，而不是治疗症状（译注：治疗感冒或支气管炎，而非咳嗽）。医生的任务不是治标，而是治本。对于PM而言，道理一模一样。

让问题暴露一段时间，或许是让大家认识到其严重性的唯一方法。很多父母都会说，他们的小孩吃一堑才长一 智——例如，不去摸滚烫的炭炉——若小孩自己被炭炉烫伤一次后，他们自然会明白那东西是摸不得的。在产品开发过程中，存在着同样的道理。当你试图请同事修 改或改进某功能时，你需要解释这是为了什么。如果大家不明白改进的意义，自然会无动于衷。

举个例子，假设你发现团队使用的需求管理软件存在着很大的问题，假如你希望马上修改它，或许得花大量精 力去告诉大家修改的意义，还得制作demo 进行 说明。但如果让这个需求管理软件继续运转一段时间，让它自己暴露出弱点，可能是一种更好的办法。因为需求管理软件的问题，在新产品上线前，你会发现有些最 初制定的需求并没有实现。此时，你可以告知大家这些遗漏的需求，但是不需要为之耽误了上线时间。如果你是正确的，要不了多久，大家就会意识到，因为使用了 那个糟糕的需求管理软件，才导致产品出现一些无法挽救的Bug。

提醒，本方法需十分小心的使用。作为PM，就算你本意是为了让同事们更透彻的看清问题，也不能忘了你是该产品最终成败的负责人。所以多数情况下，使用本方法时，最好选择小项目来作为案例。

问题可能没有你想象中那么严重。每次问题出现的时候——产品暴露了Bug，用户发出抱怨，会议上的争论——看上去总是迫切得非解决不可。于是，PM不得不暂时暂停正在进行的真正关键工作——战略、计划、用户调研——而把精力用在四处“灭火”上。

然而，必须立即解决的Bug其实很少。同时，与PM应该着重思考的产品方向等问题比起来，这些Bug的重要性实在很低。每个 Bug都有看上去万分关键的时刻，但过段时间后，它们似乎都变得无关紧要了。事实上，真正严重的Bug会迅速暴露出来。牢记这一点，会让PM把时间用在刀 刃上，而不是每天都在处理危机。

花更多的时间可以找到更完美的解决方案。若在全面了解Bug之前，就急着去为Bug寻找答案，我们通常会选择脑海中冒出来的第一 个解决方案。这可能也算是一个过得去的方案，不过若我们花更多时间来分析此Bug，找到其根本诱因，甚至来一场头脑风暴，或许我们能发现更完美的解决方 案。当然了，花更多时间也不一定就找得到更棒的方案，但至少，花了时间之后，得到的不会是更少的备选方案或更差的解决方案。

下一次遭遇Bug时，请别十万火急。PM需要有战略眼光（不是战术），请先分析Bug，找到根本诱因，并衡量全局重要性，再对 Bug进行解决。若不是每一次都着急解决每一个Bug，PM可以花更少的时间四处“灭火”，从而拥有更多的时间去思考产品战略——如何给用户带去更多的价 值。

公司招你进来，其实最重要的就是看到你的工作能力和工作态度是可以接受的。

工作能力指你能满足他们的工作期望，或者在可接受的时间范围内，经过培训后，可以满足这个工作期望。

工作态度指你能有些做职员的基本素质。

这个道理应该所有人都清楚。但是到实际事情时候就经常犯迷糊。下面几点是经常会出问题的地方：

1、不经测试，Review，就认为自己工作完成了。

你的代码或者应用一旦被别人Review ，或者进行试用。这时候你代码的好坏，或者功能是否在各种场景下是否可用，都会影响你这个人在上级及同事眼里的可信任度。

代码书写的规范，性能的高质量，各种功能在各个场景都可用，则表示你这个人是完全可信的。下次上级给你分派任务的时候，就可以给你更多的自由度来发挥。长此以往，前途和钱途自然就随手可得。

反之，代码不规范，功能好些场景不可用。这只能让上级或同事觉得你不可信任。每次都需要处理你带来的这些问题，说恶心点就是你每次拉完大便都没擦屁股，每 次都得你的同事和上级帮你擦屁股。数次都这样后，上级或同事下次跟你沟通的时候就会觉得你这个人不可信任，一件事情必须反复多次强调，总觉得你还会作出问 题。你的信用已经非常危险了。

你在别人眼里的信用就这样被你慢慢透支了。透支到一定程度，走人吧。整个团队的效率会因为你而变慢（每个人跟你沟通的成本都会影响到他本人的产出），你不走人谁走人。

2、最短可接受的工作时限

你有没有统计过，公司分派给你一个工作时候，上级指定的这项工作计划做多久的预计，跟你自己的预计有多大差异？

如果你预计时间大于上级给的工作计划时间，同时上级没有增派人手进行相关工作。除了BT的领导外，那只有一种情况：上级对你的工作态度非常不满，认为你的薪水对应的工作能力不是这么点。

对于刚工作的，更多的是你表现出来的工作能力在公司的平均工作能力之下。同时公司觉得你对工作没有表现出足够的热情。 一个能力在平均水平下面，又缺乏工作激情的人，他的前途在那里？？

如果这个人还没有表现出几个月后能达到平均水平之上的希望，为啥会留这样一个人呢？

3、工作能力不等于技术水平

我曾看到过有人抱怨说大公司的员工也不过是这技术水平， 这么简单的技术问题都不会。我自己早期也有这样想法，后来发现是不对的。

不论大公司还是小公司，要得是解决问题的工作能力。 我的曾经手下就有好几个技术水平很牛的，但是作出来的应用却一次次返工的。为啥，工作能力这些非技术因素他们做的很不好。

工作能力的非技术因素包括的很多： 责任心，表现就是对自己写出来的代码有一定要让人放心的责任； 沟通能力，一个典型的表现就是需求不理解或者需求不明时，及时得跟相关人沟通，而不是自己先按自己想法实现，造成代码写完后再返工的恶果等等。

技术水平低，但是解决问题能力强的，我也碰到过一些人。 工作的能力更重要的是这些非技术的工作能力，而不是技术水平。技术人员很容易技术水平高，但是非技术的工作能力差。 这是很糟糕的。

4、发展潜力，学习能力

公司使用的技术不可能一直不变，一直不变的公司只能慢慢被市场淘汰。这就要求员工能不断的学习新的知识，并应用到工作中来。

要想不会出现几年后，自己发现跳槽找个工作都没人要，赶快学习吧。

坚持，是一个人最难做到的。 但是不坚持，那就等着灭亡吧。

5、笨鸟先飞

一个人，在公司，如果工作能力在平均线以下， 加班吧， 不要有任何幻想。

最可怕的是自己没这个意识， 自认为自己技术水平很牛， 但是解决问题的工作能力却在平均水平线以下， 眼高手低 ， 这样的人， 公司是不能留的。

6、承诺到的事情一定要做到，不要找理由

一件事情没有被做完，想找理由能找很多的。既然你承诺了某个时间点前完成，就不要再找各种理由推脱。

公司同事和上级虽然可能这次接受了你的理由，但是下次呢， 慢慢的就会让你的上级，同事觉得你是一个喜欢推托的人。 感觉你干事是非常不可靠的。不知道那次就会不完成，下次谁敢再找你干事？

可能很多人在看到我这篇博客的时候，觉得我写的很刻薄，好像都是从公司的角度欺压技术人员。很没有人情味。

只要你不是公司的董事， 你永远是被剥削者，公司的目的就是利润最大化，这是公司存活的根本目的。作为普通的职员，要有所为的白领意识，其实就是被剥削意识。这是个适者生存的生态圈，不适用的人只能被淘汰。

实际的公司其实有很多人情味在里面，或者同事和领导有些话不便于说出口。 这也就造成了一些技术人员被开除，还自以为如何如何？ 都是没有这些意识造成的。我写这篇博客就是希望能增加技术人员的这些意识，不要犯了这些问题还自己不知道。

架构设计的几个心得：

一，不要过设计：never over design

这是一个常常被提及的话题，但是只要想想你的架构里有多少功能是根本没有用到，或者最后废弃的，就能明白其重要性了，初涉架构设计，往往倾向于设计大而化 一的架构，希望设计出具有无比扩展性，能适应一切需求的增加架构，web开发领域是个非常动态的过程，我们很难预测下个星期的变化，而又需要对变化做出最 快最有效的响应。。

ebay的工程师说过，他们的架构设计从来都不能满足系统的增长，所以他们的系统永远都在推翻重做。请注意，不是ebay架构师的能力有问题，他们 设计的架构总是建立旧版本的瓶颈上，希望通过新的架构带来突破，然而新架构带来的突破总是在很短的时间内就被新增需求淹没，于是他们不得不又使用新的架构
web开发，是个非常敏捷的过程，变化随时都在产生，用户需求千变万化，许多方面偶然性非常高，较之软件开发，希望用一个架构规划以后的所有设计，是不现实的

二，web架构生命周期：web architecture‘s life cycle
既然要杜绝过设计，又要保证一定的前瞻性，那么怎么才能找到其中的平衡呢？希望下面的web架构生命周期能够帮到你

所设计的架构需要在1－10倍的增长下，通过简单的增加硬件容量就能够胜任，而在5－10倍的增长期间，请着手下一个版本的架构设计，使之能承受下一个10倍间的增长

google之所以能够称霸，不完全是因为搜索技术和排序技术有多先进，其实包括baidu和yahoo，所使用的技术现在也已经大同小异，然而，google能在一个月内通过增加上万台服务器来达到足够系统容量的能力确是很难被复制的

三，缓存：Cache
空间换取时间，缓存永远计算机设计的重中之重，从cpu到io，到处都可以看到缓存的身影，web架构设计重，缓存设计必不可少，关于怎样设计合理的缓 存，jbosscache的创始人，淘宝的创始人是这样说的：其实设计web缓存和企业级缓存是非常不同的，企业级缓存偏重于逻辑，而web缓存，简单快 速为好。。

缓存带来的问题是什么？是程序的复杂度上升，因为数据散布在多个进程，所以同步就是一个麻烦的问题，加上集群，复杂度会进一步提高，在实际运用中，采用怎样的同步策略常常需要和业务绑定

老钱为搜狐设计的帖子设计了链表缓存，这样既可以满足灵活插入的需要，又能够快速阅读，而其他一些大型社区也经常采用类此的结构来优化帖子列表，memcache也是一个常常用到的工具

Cache的常用的策略是：让数据在内存中，而不是在比较耗时的磁盘上。从这个角度讲，mysql提供的heap引擎（存储方式）也是一个值得思考的方法,这种存储方法可以把数据存储在内存中,并且保留sql强大的查询能力,是不是一举两得呢?

我们这里只说到了读缓存，其实还有一种写缓存，在以内容为主的社区里比较少用到，因为这样的社区最主要需要解决的问题是读问题，但是在处理能力低于 请求能力时，或者单个希望请求先被缓存形成块，然后批量处理时，写缓存就出现了，在交互性很强的社区设计里我们很容易找到这样的缓存

四，核心模块一定要自己开发：DIY your core module
这点我们是深有体会，钱宏武和云风也都有谈到，我们经常倾向于使用一些开源模块，如果不涉及核心模块，确实是可以的，如果涉及，那么就要小心了，因为当访 问量达到一定的程度，这些模块往往都有这样那样的问题，当然我们可以把问题归结为对开源的模块不熟悉，但是不管怎样，核心出现问题的时候，不能完全掌握其 代码是非常可怕的

五，合理选择数据存储方式：reasonable data storage
我们一定要使用数据库吗，不一定，雷鸣告诉我们搜索不一定需要数据库，云风告诉我们，游戏不一定需要数据库，那么什么时候我们才需要数据库呢，为什么不干脆用文件来代替他呢？
首先我们需要先承认，数据库也是对文件进行操作。我们需要数据库，主要是使用下面这几个功能，一个是数据存储，一个是数据检索，在关系数据库中，我们其实非常在乎数据库的复杂搜索的能力，看看一个统计用的tsql就知道了(不用仔细读,扫一眼就可以了)

select   c.Class_name,d.Class_name_2,a.Creativity_Title,b.User_name,(select   count(Id)   from   review   where   Reviewid=a.Id)   as   countNum   from   Creativity   as   a,User_info   as   b,class   as   c,class2   as   d   where   a.user_id=b.id   and   a.Creativity_Class=c.Id   and   a.Creativity_Class_2=d.Id
select   a.Id,max(c.Class_name),(max(d.Class_name_2),max(a.Creativity_Title),max(b.User_name),count(e.Id)   as   countNum   from   Creativity   as   a,User_info   as   b,class   as   c,class2   as   d,review   as   e   where   a.user_id=b.id   and   a.Creativity_Class=c.Id   and   a.Creativity_Class_2=d.Id   and   a.Id=e.Reviewid   group   by   a.Id ……………………………………….

我们可以看出需要数据库关联，排序的能力，这个能力在某些情况下非常重要，但是如果你的网站的常规操作，全是这样复杂的逻辑，那效率一定是非常低 的，所以我们常常在数据库里加入许多冗余字段，来减小简单查询时关联等操作带来的压力，我们看看下面这张图，可以看到数据库的设计重心，和网站(指内容型 社区)需要面对的问题实际是有一些偏差的

同样其他一些软件产品也遇到同样的问题所以具我了解，有许多特殊的运用都有自己设计的特殊数据存储结构与方法，比如有的大型服务程序采取树形数据存储结构，lucene使用文件来存储索引和文件

从另外一个角度上看，使用数据库，意味着数据和表现是完全分离的（这当然是经典的设计思路），也就是说当需要展示数据时，不得不需要一个转换的过 程，也可以说是绑定的过程，当网站具备一定规模的时候，数据库往往成为效率的瓶颈，所以许多网站也采用直接书写静态文件的方法来避免读取操作时的绑定

这并不是说我们从今天起就可以把我们亲爱的数据库打入冷宫，而是我们在设计数据的持久化时，需要根据实际情况来选择存储方式，而数据库不过是其中一个选项

六，搞清楚谁是最重要的人：who’s the most important guy
在用例需求分析的时候常常讲到涉众，就是和你的设计息息相关的人，在web中我们一定以为最重要的涉众莫过于用户了。，在一个传统的互动社 区开发中，最重要的东西是内容，用户产生内容，所以用户就是上帝，至于内容挑选工具，不就是给坐我后面三排的妹妹们用的吗？凑或行了，实在有问题我就在数 据里手动帮你加得了。。这大概是眼下许多小型甚至中型网站技术人员的普遍想法。钱宏武在他的讲座里谈到了这个问题：实际上网站每天产生的内容非常的多，普 通人是不可能看完的，而编辑负责把精华的内容推荐到首页上，所以很多用户读到的内容其实都依赖于编辑的推荐，所以设计让编辑工作方便的工具也是非常重要， 有时甚至是最重要的。

七，不要执着于文档：don’t be crazy about document
web开发的文档重要吗？什么文档最重要？我的看法是web开发中交流>文档，

现在大的软件公司比较流行的做法是：
注重产品设计文档，在这种方法里，产品文档非常详尽，并且没有歧义，开发人员基于设计文档开发，测试人员基于设计文档制定测试方案，任何新人都可以通过阅读产品设计文档来了解项目的概况

而web项目从概念到实现的时间是非常短的，而且越短越好，并且由于变化迅速，要想写出完整的产品和需求文档是几乎不可能的，大多数情况是等你写出 完备的文档，项目早就是另外一个样子，但是没有文档的问题是，如果团队发生变化，添加新成员怎样才能了解软件的结构和概念呢，一种是每个人都了解软件的整 个结构，除非你的团队整体消失，否则任何一个人都能够担当培养新人的责任，这种face2face交流比文档有效率很多。

于是就有了前office开发者，现任yahoo中国某产品开发负责人的刘振飞所感觉到的落差，他说，我们的项目是吵出来的，我听完会心一笑

八，团队：team
不要专家团队，而要外科手术式的团队,你的团队里一定要有清道夫，需要有弓箭手，让他们和项目一起成长，才是项目负责人的最大成就

总结：

架构是一种权衡

web开发的特点是是：没有太复杂的技术难点，一切在于迅速的把握需求，其实这正式敏捷开发的要旨所在，一切都可以非常快速的建立，非常快速的重构，我们的开发工具，底层库和框架，包括搜索引擎和web文档提供的帮助，都提我们供给了敏捷的能力。

此外，相应的，最有效率的交流方式必须留给web开发，那就是face2face（面对面），不要太担心你的设计不能被完备的文档所保留下来，他们会以交流，代码和小卡片的方式保存下来

人的因素会更加重要，无论是对用户的需求，还是开发人员的素质。