我觉得JAVA语言应该新增一个“子类可见”的Access Modifier
目前 "protected" 关键字代表 包可见和子类可见，但其实很多情况下，我们只希望提供子类可见，不提供包可见（比如 抽象类里的成员变量）。但JAVA没有提供这种Access Modifier，很遗憾。虽然我们可以通过其它办法来变通实现，但终归是很不方便。
［对谈录］“让主角穿好衣服”究竟是演员的职责还是导演的职责？
如果要让剧中的主角要穿上西服， 导演 会 让 主演 去干这件事， 那么在建模时，“穿衣服”到底算演员的职责，还是导演的职责呢？ 关于这类问题的争论，可能是建模时争议次数最多的，而且争论双方一般都很难说服对方。 A： 穿衣服是演员的份内事（封装），而且不同的演员有不同的穿衣顺序（多态），导演不需要关心演员是怎么穿的，只需要演员能穿好衣服出镜就行了 B: 演员不过是导演的木偶（贫血者），具体怎么穿应该让导演来定（Transaction Script），尤其在当穿衣需要他人辅助时（数据库，JNDI 等资源），更加只有导演才能做好，因为导演才能调配这些资源（在Script中注入资源或通过工厂生成资源） A：若演员穿衣需要调配其它资源，那的确应该让导演承担这个职责；否则的话，应该把把穿衣置为演员的职责，这样可以实现较好的封装和多态；否则的话，如果把这个职责丢给导演，那么，首先导演的封装性不太好，其次一个导演要实现所有演员的穿衣逻辑，这要造成较多的if/else（影响代码简洁性），或者要把导演本身进行多态设计（这一般不好做，因为导演的singleton被破坏，一些资源也不好处理，比如事务、AOP什么的） B：话虽这样说，但是在我们公司的整体架构下，演员这种东西仅仅是数据结构，它是静态的，它不应该封装什么奇怪的算法；而导演才是动作者，导演才有权力干活。这样的设计思路更容易让人理解，并且这样做有利于维护我们系统设计风格的一致性! A: ……. B： …….
关于网络信息安全的对谈录
场景：张三向李四写一封信 菜鸟1：送信途中有人私拆信件，偷看信件内容，咋办？ 大师：将信件内容（ 明文）转换（ 加密）成一串莫名奇妙的数字和字母（ 密文），偷看者看不懂，但是李四可以采用跟张三事先约定的办法，将密文变回（ 解密）信件内容。 菜鸟2：具体用什么办法来加密和解密呢？ 大师：办法很多。最直接的一种就是采用一对公开的加密/解密算法，双方再打电话约定一个口令（ 密钥），张三通过加密算法和口令将信件加密，李四收到密文后，再用解密算法和口令将密文解密。私拆信件的人虽然知道解密算法，但是没有口令，所以无法将信件内容解密。 菜鸟3：还要打电话约定口令啊？这多麻烦。如果电话也有人偷听怎么办？还有，如果张三不认识李四，怎么打电话啊？ 大师：口令的传输的确很麻烦。干脆这样，口令就不传了，只有自己知道（ 私钥）。那怎么加密解密呢？伟大的数学家们给收信者李四想出了一个完美的办法。他除了有一个秘密的口令，同时还在脑门上贴一个公开的口令（ 公钥），这个口令谁都知道。张三写信时，用这个公开的口令加密信件，而加密后的内容只有通过李四的私钥才能解密。所以，私拆信件的人就没办法了。 菜鸟4: 嗯，信件加密的问题是解决了。不过，我突然想到一个问题。张三写信骂了李四，然后李四找他当众理论，张三却百般抵赖，说这封信是电脑打出来的，不是他的笔迹，怎么办？ 大师：那就要让张三写信时在信尾签名（ 数字签名）。 菜鸟5: 签名要不要加密啊？否则私拆信件的人知道张三跟李四有来往，多不好 大师：要的。张三用自己的私钥将签名加密，李四再用张三脑门上的公钥将它解密。 菜鸟6：有人说张三是个大骗子。他其实是个流串犯，真名叫王二流子，然后冒名叫做张三。 大师：验他的身份证（ 证书）。身份证会写他的名字，和他的公钥（就是他脑门上那个） 菜鸟7：身份证是谁发的啊？ 大师：当然是公安局了（ 认证中心，CA）。 菜鸟8：如果连他的身份证都是假的呢？ 大师：每个合法的身份证，都是经过公安局签发的，公安局提供提供了一套防伪技术。具体来说，公安局会通过自己的私钥将张三的身份证加密（没错，公安局本身也有密钥）后再发给张三，李四如果怀疑张三，可以用公安局的公钥将张三的身份证解密，然后看一下里面的名字是不是“张三”。如果王二流子想以“张三”的名义伪造身份证，那他要把公安局也收买了才行。 菜鸟9：嗯，这下无懈可击了。不过，你别嫌我话多，我问最后一个问题，如果私拆信件的人吃饱了没事干，在信件里插入了几句话，李四收到后肯定会莫名奇妙的，怎么办？ 大师：这难不倒伟大的数学家们。他们规定，张三写完信后，要付上信件内容的 摘要，这个摘要也是一串看不懂的东西，并且，没办法反转回来。具体怎么摘要，也是数学家们规定好的。李四收到信后，也把信件内容进行一下摘要，然后再和张三附的摘要比对一下。如果拆信的人偷改了信件的内容，那么进行摘要后就和张三附的原摘要对不上了。这时李四就不会把这封信当真了。
《网上支付与结算》读书笔记_03_网上支付模式及结算方式
1.网上支付系统有七大要素： a. 客户，商家，开户行，收单行 b. CA认证机构 c. 金融专用网 及 互联网–金融专用网之间的支付网关 专用网 指银行内部及银行间的资金清结算网络，有比较高的安全性 支付网关 则负责在专用网和公网之间传递数据，它要对数据进行转换、加密等 2.网上支付模式分类 a.银行卡支付 A.无安全措施。 顾客把卡号密码都给商家，商家去银行支付 B.基于第三方代理。 顾客和商家把自己的信息告诉一个可靠的第三方代理，代理去银行支付. CyberCash, FirstVirtual etc. C.基于SSL。 顾客在SSL协议的保护下，去开户行的页面支付，银行再把支付确认信息反馈给商家。 D.基于SET安全协议。 b.电子票据支付 顾客通过开户行生成电子支票，付给商户 c.电子现金支付 把货币存储在卡上或硬盘数据文件里，可以脱机，匿名交易 d.电子钱包支付 VISACash等 3.支付网关的分类 a.银行支付网关. 银行自建网关，不过现在一般都已整合到网上银行中了 b.网上银行 c.共建支付网关.由央行或发卡组织牵头建设的支付网关，比如ChinaPay d.第三方支付. 支付宝，安付通等 …
Spring MVC SimpleFormController 详细流程图
看了好久的代码，终于搞清楚了 阅读顺序： 1.《请求表单_流程》 2.《非Session_Form的提交》 3.《Session_Form的正常提交》 4.《Session Form的非正常提交》
银行卡的两种介持类型：磁卡 和 IC卡
磁卡用磁性材料记录卡信息，IC卡则通过芯片记录 存储介质的特性决定了这两种卡的区别： 1.磁卡安全性更弱。因为磁条信息容易破译和仿制，IC卡则不同。 2.磁卡必须要网络实时授权。由于磁卡安全性弱，因此必须通过网络实时授权控制，不能脱机处理。 3.IC卡可以脱机记账。因为它的存储容量比较大。
《网上支付与结算》读书笔记_02_银行卡支付
本贴内容： 银行卡概述 -> 银行卡交易中的角色 -> 银行卡的交易与结算流程 -> 银行卡的网上支付 1.银行卡概述 关键功能：一种信用凭证。官方定义的功能： 消费信用，转账结算，存取现金 2. 参与交易的各方 持卡人－－ 发卡行－－－－银行卡组织(银联)－－－－－－收单行 －－商户 3.交易与结算流程 流程分为两部分：交易流程 和 清算流程。从财务的角度说， 交易过程就是记录债务，清算过程则是将债务清偿 a.交易流程 i.持卡人在商户那里刷卡 ii.收单行先判断这张卡能不能用。它会把刷卡的请求通过银行卡组织，间接地向发卡行请求交易授权 iii.发卡行同意授权，就把授权应答通过银行卡组织传回给收单行。这时候持卡和商户就可以交钱交货了 iv.剩下的过程就是记账： 持卡人：产生对发卡行的债务（信用卡里要多还一笔钱） 商户：产生对收单行的债权（凭证就是POS机打印出来的签购单） 收单行：产生－－对商户的债务 ＋ 对发卡行的债权 发卡行：产生－－对收单行的债务 ＋ 对持卡人的债权 注： A.还有一些交易佣金的账务，这里就不注明了 B.若持卡人使用的是借记卡，则持卡人和发卡行实行清算，不发生新的债务关系 …
《网上支付与结算》读书笔记_01_问题概述
《网上支付与结算》，张宽海著，机械工业出版社 —————————————————- 背景知识：支付模式的发展 啥是支付结算？就是债务的清偿 物物交换 -> 物币交换 -> 银行划账。总之，支付结算离不开银行的参与 背景知识：中国的支付体系 三票一卡，同城票据交换所，支付系统 我国的支付系统： 1.央行现代化支付系统 a.大额实时支付系统：支付指令单笔实时发送 b.小额批量支付系统：支付指令批量发送 2.全国支票影像交换系统 例：我行通过该系统将支票影像传给贵行，贵行再通过小额批量支付系统付款给我行 3.各银行金融机构内部的行内支付系统 4.银行卡支付系统：主要指银联跨行支付系统，处理银行卡跨行交易信息转接和交易清算业务 ================================================================ 网上支付的两大问题： 1.钱货不能同时两清–买卖双方的互信问题 2.信息安全问题 网上支付发展的阶段： 1. 网上交易，线下支付 2.线上支付 a. 买家购买商家提供的预付费卡，交易时用卡付费 — 缺点是这种卡流动性太弱 b.买家 通过银行认可的网上支付工具付钱 我个人认为，这种模式还可以再细分： i. 按支付是否与订单挂钩来分 …
用URL作为资源，实现可配置的权限管理 — 这样真的好吗？
用URL作为资源的意思是：将 访问某URL 定义为一个权限，只有拥有了该权限的用户，才可以请求该URL。 这样做的好处是： 1.实现可配置的权限管理。也就是说URL资源不必写死，可在生产环境中修改。 2.还可以将权限逻辑从业务逻辑中提成出来 —- 代码里不用判断权限，在后台配一下即可，以后改变权限逻辑时，也不需要修改代码 这两个好处是确切的，但是它在发布时存在一定的负面作用： 1.url定义要么在后台界面手动配，要么写在配置文件里，要么作为SQL写到数据库中。这些东西不是高级语言代码，没法用编译器防止“语法”错误，因此出错率很高 2.开发人员在开发调试时，一般会写一个功能，配一个权限，由于耐心、急躁等因素，等功能全部完成时，权限定义的配置却没有统一记录，等到系统测试时才恍然大悟！ 3.由于测试环境和生产环境的不同，权限定义从测试移到生产之前，往往要做很多改动才行，这也增加了出错率，提高了烦恼程度 4.一个系统中， URL定义 一般会有很多， 本身维护起来就麻烦
extremeTable比displayTag好用
跟displayTag相比，有下列优点： 1.提供表内搜索功能，不需要手工开发搜索程序 2.排序时是整表排序，而不是像displayTag那样只能页内排序