WebWalker

很多书上都有讲到OOP设计的原则，这个是所有设计的基础参考规则，非常重要哦，我这里也照单罗列一下：其中主要的几个原则为SOLID原则，概要如下：1、单一原则（S）      应当对扩展开放，对修改封闭2、开闭原则（O）      就一个类而言，应当只专注做一件事3、里氏替换（L）      所有抽象基类出现的地方都应该出现子类4、接口隔离（I）      要针对

/**************************************************************************************************** 设计思想需要归纳与提炼，无论简单抑或复杂。当然方案未必是唯一的最佳路径，在总结** 的过程中发现问题、改善问题；只有跳出业务，将复杂问题简单化，才能提纲挈领，寻找** 共性与变化的制高

/**************************************************************************************************** 模式的初衷，无非是为我们经常出现问题的业务逻辑或系统结构提供好的解决方案，不论** 是高层的还是较低层次的；而应用模式的主要工作则是模式识别，能将单一或复合的模式** 结合项目自身的业

由于最近工作中，涉及到生产者消费者设计模式，对此有一些体会，所以总结一下，与大家分享。 什么是生产者消费者模式在工作中，大家可能会碰到这样一种情况：某个模块负责产生数据，这些数据由另一个模块来负责处理（此处的模块是广义的，可以是类、函数、线程、进程等）。产生数据的模块，就形象地称为生产者；而处理数据的模块，就称为消费者。在生产者与消费者之间在加个缓冲区，我们形象的称之为仓库，生产者负责

/**************************************************************************************************** 模式的初衷，无非是为我们经常出现问题的业务逻辑或系统结构提供好的解决方案，不论** 是高层的还是较低层次的；而应用模式的主要工作则是模式识别，能将单一或复合的模式** 结合项目自身的业

UML类图和UML对象图（对象是类的实例，那么对象图就是类图的一个实例，类图类名下面无下划线，而对象图是有的）： 一、依赖关系（Dependence）：假设A类的变化引起了B类的变化，则说名B类依赖于A类。依赖关系有如下三种情况：1、A类是B类的一个成员变量；2、A类是B类方法当中的一个参数；3、A类向B类发送消息，从而影响B类发生变化；使用带箭头的虚线表示 p

每个大型的网站都有自身类型特征的架构方案与经验，电商、书城、搜索、B2B、B2C、SNS等等，各有千秋，在实际的项目开发、架构设计中我们可以适当参考，并结合自身土生土长的业务特色，进而少走一些弯路，本系列文章仅负责收集并不断更新架构与选型，不涉及到具体细节的把握（当然也提供不了具体的细节^_+），另外文献言及的架构方案未必是最新的，仅供参考。 § 大型SNS网站后台架构对比 1、国

所谓适配，也就是要看服务提供者如何设计实现，如何暴漏接口。      现有服务端提供收单、校验、支付等服务环节，客户端业务横向扩展的强度比较大，且有诸多共性存在，考虑到职责分离、调用的统一性，所以将业务分类做数据配置，根据配置执行不同的解析类，如下：§ 实现类图       § 业务分类配置       § 代码

/**************************************************************************************************** 设计思想需要归纳与提炼，无论简单抑或复杂。当然方案未必是唯一的最佳路径，在总结** 的过程中发现问题、改善问题；只有跳出业务，将复杂问题简单化，才能提纲挈领，寻找** 共性与变化的制高

/**************************************************************************************************** 设计思想需要归纳与提炼，无论简单抑或复杂。当然方案未必是唯一的最佳路径，在总结** 的过程中发现问题、改善问题；只有跳出业务，将复杂问题简单化，才能提纲挈领，寻找** 共性与变化的制高

很多时候，单例、静态类的区别和使用场景一直纠缠不清，也比较容易混淆，我整理分析了一下，现将相关区别、联系与使用场景做如下描述： § 单例1、单例可以继承类，实现接口，体现OOP思想2、单例可以被延迟初始化3、单例类可以被集成，它的方法可以被覆写；也就是可以多态4、垃圾回收：产生的唯一实例会一直驻留在内存中5、使用场景：（1）不存在比较复杂的事务管理，用单例比较好，e

这学期开始，正式开始了复旦MSE工程硕士的在读生涯，其教学计划中有一门选修课程为《客户关系管理》，一向习惯了理工科的我想换换口味，也希望从另一个角度开阔一下视野，所以毫不犹豫的选择了它，乍看上去貌似跟技术工程毫无关系，而时至目前为止才发现，需要按照老师上课时讲述的各方面技术，分小组完成一次CRM的课题作业报告，真是偷鸡不成折把米！不过说来也是1、2周前的事，现在已经初步完成，当然报告...

业务、应用系统最常用的就是基于数据的查询，这不同于宏观意义上的系统各个层面优化（应用端、服务端、DB端等等），基于数据的查询更多时候需要考虑数据的规模、用户的习惯、数据的变化性等因素，但同时数据查询的优化也贯穿着系统的各个层面。本文主要针对一个特定领域进行分析，以供各位参考！       基于数据的查询往往首要考虑的是缓存数据，那么缓存的前提：       1、数据不会实时变化

发现距离上一篇博文之后，沉寂了不少时日，好久没写文章了；这段时间以来一直比较忙，为着工作、面试（其实也没面几家）、试用期、新技术新业务；本打算写写就移动互联网方面的开发写写心得、总结，但碍于周末还要上课、考试……，所以偶只能将这里暂时荒置；当然我写博文的初衷不是为了最终有多少读者，只把这里当做是我个人总结、成长的一个经历和阶段的脚印，同时也希望能为相关人士带来少许的帮助，写的不当之处，还请爱心人士

/**************************************************************************************************** 模式的初衷，无非是为我们经常出现问题的业务逻辑或系统结构提供好的解决方案，不论** 是高层的还是较低层次的；而应用模式的主要工作则是模式识别，能将单一或复合的模式** 结合项目自身的业

/**************************************************************************************************** 模式的初衷，无非是为我们经常出现问题的业务逻辑或系统结构提供好的解决方案，不论** 是高层的还是较低层次的；而应用模式的主要工作则是模式识别，能将单一或复合的模式** 结合项目自身的业

抽象类与接口在很多时候是混用的，有关它的概念与区别很多兄弟可能一直纠缠不清，不知道何时在何种场景中采用接扣和抽象类，当然网络上也有不少此类知识的介绍，在实际使用中我将其简单的归纳如下：  § 抽象类1、抽象类是模板      可以有普通成员变量、普通方法、抽象方法、构造方法2、修饰符可以为私有3、只能继承一个抽象类      偏向于Is-A关系，当然子类可以不用重写抽象

/**************************************************************************************************** 设计思想需要归纳与提炼，无论简单抑或复杂。当然方案未必是唯一的最佳路径，在总结** 的过程中发现问题、改善问题；只有跳出业务，将复杂问题简单化，才能提纲挈领，寻找** 共性与变化的制高

规则验证，顾名思义—针对特定的数据格式或业务规则选用特定的规则完成合法性验证。本文描述这样的一种简单场景：       大量终端用户通过应用系统提交模板信息，从而在服务端批量完成业务处理（支付、充值、转账、……），当然数据存在复杂、不确定性，故此可通过设定模板中指定行列的数据格式，批量完成特定行列的格式校验，通过将规则DB化，一方面可后期维护动态变化的规则项， 另一方面也有利于流程性业务类规则

有关系统权限的设计，有诸多的方案&实现方法，甚至不乏有权限相关的通用组件，当然这些可能都局限于特定的业务场景，简单的抑或是复杂的，正如它不可能真正满足所有的需求；本文通过另一个维度来实现系统权限的控制，当然系统方案的采用主要由系统的业务场景决定，整个实现过程相对繁杂，点到为止。§ 概述根据业务性的需要，本次设计复合了以下模式：1、组合   将权限结构组织成树状结构，使整

曾经兴致盎然的要将XX系统重构改造，结果始料未然，半途而废。总的来说，执行难度之大，风险之大，尤其是被决策层重视的成本问题。既是败笔，亦可贴出来消遣娱乐一番，以安抚蠢蠢躁动的心。§ 愿景1、 我们遇到的问题2、 愿景§ 业务建模1、业务对象2、 业务序列（1）现状业务序列涉及内部业务，仅画出单一业务流程PROCESS（2）...

内部接口的定义与实现各有千秋，本文所提到的是这样的思路：通过内部通用的方法完成“路由”转发，这样做的好处，不言而喻：单点控制风险、通用逻辑校验、流量控制……等等。直接上代码： public class MerchantPayment : IMerchantPayment { #region IPaymentClient 成员 //

/**************************************************************************************************** 设计思想需要归纳与提炼，无论简单抑或复杂。当然方案未必是唯一的最佳路径，在总结** 的过程中发现问题、改善问题；只有跳出业务，将复杂问题简单化，才能提纲挈领，寻找** 共性与变化的制高

单点登录SSO（Single Sign On）想必大家都耳熟能详，企业信息化过程中会不断的衍生出不同技术平台、不同业务范围、不同场景的应用或支持系统，与此同时我们也有可能会因为高层架构的决策会采用SSO这种模式来组织、细化不同职责的子系统登录；总的来说SSO的好处如下：1、从扩展性层面上，提供了统一的标准，便于不同时期APP的部署与接入2、从兼容性方面，便于不同技术平台的应用系...

网站、服务以及对外提供的接口等几乎所有的B/S、C/S应用，在运营的过程中，往往都有可能会遇到意想不到的暴力型攻击威胁，通常所说的有两类：恶意刷新、暴力破解（穷举），当然也不乏有应用漏洞扫描等，实现方式多样，大致有以下情形：（1）   暴力猜测密码等敏感信息（2）   恶意刷新页面，致使服务器处于繁忙应答状态（3）   穷举验证码（4）   后台扫描（5）   合法业务的不合法

1、DFD时如果直接拖动数据流的图示  对我们来说不是很好的调节 方向      所以这个时候 可以先点击上面的连接线 然后点击数据流图示      这个时候就可以自由的控制带箭头的 数据流了2、向Visio中粘贴 复制的图示或外部资源时 将文档空白处移到屏幕中心 然后再粘贴 不会覆盖现有的图示3、直接拖动数据流图示的箭头，让其折线后 进行延伸 有时并不好实现，可以在折线一半的时候 按住折线中间的