why is this

部分参考自《大话设计模式》《设计模式之禅》单一职责原则：避免写牛类，类似在as3里，文档类不要写太多逻辑，而应该尽量只负责进行对象的实例化new  和 参数初始化等工作接口职责单一，不过分耦合不关联的方法在同一个接口里方法职责单一，比如修改用户姓名、电话、身份证数据，尽量不通过一个方法传入多个参数去同时修改，而是分成对应一个数据一个方法，令方法粒度足够小影响类结构变

http://surlymo.iteye.com/blog/2001529?utm_source=tuicool&utm_medium=referral一、传统并发模型的缺点基于线程的并发特点：每任务一线程直线式的编程使用资源昂高，context切换代价高，竞争锁昂贵太多线程可能导致吞吐量下降，响应时间暴涨。基于事

转载：http://www.youkuaiyun.com/article/2015-11-06/2826139我一般讲模块设计的时候，都会先讲架构相关的一些东西，首先架构师必须重视的第一件事情是需求，因为架构的目的是为了满足需求，这一点千万不能搞错。谈到架构，很多人都会喜欢说，我设计了一个牛逼的框架。但是我长期以来在强调的一个观点是说，框架这种事情其实在架构哲学里面一点都不重要，框架其实是实践层面的事情，

消息队列可以把消息产生和消息处理解耦合，分离开来，并且可以避免了使用线程或进程同步的锁是一个典型的生产者消费者模式生产者生产数据入队列=>队列缓存=>消费者取数据队列采用先进先出的阻塞队列，队列前后分别有至少一个线程，前一线程负责往队列中放数据，后一线程负责从队列中取数据进行分析处理等操作经典的队列应用：1.内存队列2.无锁内存队列Rin

不要STUPID，坚持GRASP和SOLID听过SOLID编码吗？有人可能会说：这是描述设计原则的一个专业术语，由我们可爱的代码整洁之道传教者鲍勃（罗伯特C. 马丁）大叔提出，是一组用于指导我们如何写出“好代码”的原则。在编程界充满了这样由单词首字母组成的缩略词。其它类似的例子还有DRY（Don’t Repeat Yourself! 不要重复你自己！）和KISS（Keep It S

昨天购买了《程序员》杂志 2007.4期，第一时间去翻阅了一遍，其中有一篇《两种高性能I/O设计模式的比较》令人眼睛一亮，这是一篇译文，偶最近在一直想认真看看这方面的文章很久了。文章主要是讲到了系统I/O方式可分为阻塞，非阻塞同步和非阻塞异步三类，三种方式中，非阻塞异步模式的扩展性和性能最好。主要是讲了两种IO多路复用模式：Reactor和Proactor，并对它们进行了比较。文章还介绍了

分层状态机的设计：对于状态较多的状态机，通常的设计会维护一个庞大的二维矩阵，所有状态耦合在一起，这往往导致维护困难，由于可能存在许多公共的特性，也会导致许多状态具有相同的处理函数。针对这些问题我们可以通过设计分层状态机来解决，主要的思想就是根据不同的功能模块设计出多个状态机，各个状态机分布在不同的层次上。上层状态机调用下层状态机时，上层状态机入栈，下层状态机变为当前处理状态机。通常我们使用堆栈

多平台适配的代码设计一个成功的软件系统，往往需要根据需求在不同的系统平台上运行，为了解决系统在多个平台的移植带来的风险，业务架构往往会设计相应的平台适配层来隔离不同平台的差异，如何设计一个易于扩展的平台适配层，是软件设计人员需要考虑的问题。设计1：1: 提供平台接口文件os.h2：定义如下：#ifdef OS1#define OS_Fun OS1_Fun#end

有限状态机（FSM）是表示有限个状态及在这些状态之间的转移和动作等行为的数学模型，在计算机领域有着广泛的应用。通常FSM包含几个要素：状态的管理、状态的监控、状态的触发、状态触发后引发的动作。本文主要阐述一下状态机的几种设计方法。1：switch case/if else设计方法curEvent = getEvent();curState = getCurState();swi

钩子(Hook)，是Windows消息处理机制的一个平台,应用程序可以在上面设置子程以监视指定窗口的某种消息，而且所监视的窗口可以是其他进程所创建的。当消息到达后，在目标窗口处理函数之前处理它。钩子机制允许应用程序截获处理window消息或特定事件。       钩子实际上是一个处理消息的程序段，通过系统调用，把它挂入系统。每当特定的消息发出，在没有到达目的窗口前，钩子程序就先捕获该消息，亦即

Fruit.php <?php /** * @author Gonn, http://www.nowamagic.net/ */ interface Fruit { public function showColor(); } class Apple implemen

ActiveRecord也属于ORM层，由Rails最早提出，遵循标准的ORM模型：表映射到记录，记录映射到对象，字段映射到对象属性。配合遵循的命名和配置惯例，能够很大程度的快速实现模型的操作，而且简洁易懂。ActiveRecord的主要思想是：1.每一个数据库表对应创建一个类，类的每一个对象实例对应于数据库中表的一行记录；通常表的每个字段在类中都有相应的Field；2

我们为什么使用ORM?博客园在推广ORM方面的确做了很大的贡献，很多的程序员开始使用ORM，不用写SQL的喜悦让他们激动不已，可是好景不长，他们很快发现众多的烦恼一个接一个的出现了。很遗憾，我并不打算在这篇文章中解决这些问题，因为的确存在这些问题，而且目前没有完美的解决方法。那么既然这样，我们为什么要使用ORM呢？难道真的是为了不使用SQL吗？还是要看O - R ，我们为什么要

资源池：当某一个资源使用完后，资源池把相关的资源的忙标示清除掉，以示该资源可以再被下一个请求使用。1.资源池引入的目的       提高性能2.资源池运作机制       由资源池管理器提供一定数目的目标资源，当有请求该资源时，资源池分配给一个，然后给该资源标识为忙，    标   示为忙的资源不能再被分配使用，3.资源池常有的参数     1.初始资源的数目：

IoC IoC： Inversion of Control，控制反转， 控制权从应用程序转移到框架（如IoC容器），是框架共有特性 1、为什么需要IoC容器1.1、应用程序主动控制对象的实例化及依赖装配 Java代码  A a = new AImpl();  B b = new BImpl();  a.setB(b);  本质：创建对象，

首先分享一下，我在网上看到的两篇不错的文章：正是这两篇文章才理解了reactor和proactor模式; 首先就第一篇《Reactor模式，或者叫反应器模式》做一下笔记： 刚开店做生意，老板为了给顾客一个美好的印象，给顾客最好的服务，一对一: 随着经营的生意越来越好，顾客多了，不能服务员也多吧，那样得支出的成本也太大了，要是一下子来个1000个顾客，