bytxl的专栏

http://blog.jobbole.com/22509/接上篇《业务流程图绘制流程分享(一)》，本篇将对上篇中间的第四部分——如何绘制业务流程图展开更多讨论。本来写完上篇，我发现没有太多必要单纯讨论这一部分内容，因为对于很多人来讲，缺的不是具体的做法，而是做这件事情的意义以及目标性的明确。一旦对这件事情的意义和目标有深刻认同，那自然会产生较大的动力去研究How这个层次的所需方法和技

最近几天在看一本名为Dependency Injection in .NET 的书，主要讲了什么是依赖注入，使用依赖注入的优点，以及.NET平台上依赖注入的各种框架和用法。在这本书的开头，讲述了软件工程中的一个重要的理念就是关注分离(Separation of concern, SoC)。依赖注入不是目的，它是一系列工具和手段，最终的目的是帮助我们开发出松散耦合(loose coupled

---比较Backbone和Ext4.x在MVC实现上的差异 大漠穷秋 前言 圣人云：不想做妈咪的小姐不是好码农。 每一个码农的心中都有一个终极理想，那就是有一天不用再Coding。 在成为妈咪的道路上，“设计模式”被认为是一项必备的技能。 因此，经常有湿主会问小僧这样一个问题：为什么MVC不是一种设计

最近一直在抽时间研究设计模式，之前对设计模式也有一定的了解，但是都没有平心静气的去研究过，只是了解了一些皮毛，最近打算再深入研究一下，重新打开了设计模式的数据，对之前的疑问一个个的刨根问底，今天看了简单工厂模式和策略模式看的人有点小晕，两个的大概思路没有怎么变，都是通过多态去减少代码的耦合度，怎么看两个都是如出一辙，最后终于找到了两个的本质区别，在此和大家分享下：先上代码:简单工厂

1.书中举了一个鸭子类的设计，有些会飞或者会叫，有些不会飞可能也不会叫，用继承则导致不该有的功能通过继承而继承了下来，使用接口则代码无法做到最大程度的重用。进而引出设计原则1：找出应用中可能需要变化之处，把它们独立出来，不要和那些不需要变化的代码混在一起，把会变化的部分取出并封装起来，好让其他部分不会受到影响 。——每个设计模式背后的精神所在。2.我们希望运行时动态的改变一些行为，这就引出

1.M-V-C ——Model--View--Controller，模式-视图-控制器，这是一种范型。模型对象正是应用系统存在的理由，你设计的对象，包含了数据、逻辑和其他在你的应用领域创建定制的类。视图通常是控件，用来显示和编辑，控制器位于二者中间，负责将每个改变的状态送进送出。而学习设计模式是理解MVC的钥匙。书中用一个iTunes的例子直观描述了MVC：2.MVC的基本原理

http://www.cnblogs.com/wanggary/archive/2011/04/08/2009965.html代理，一看名字就知道这只是个中介而已，真实的执行者在代理的后面呢。cbf4life在他的书里提的例子也很有趣，更详细的内容及说明可以参考原作者博客：cbf4life.cnblogs.com。现在贴代码，以方便随用随取。2.1.解释main()，西门庆

http://www.cnblogs.com/wanggary/archive/2011/04/09/2010876.html单例模式看起来也蛮简单的，就是在系统中只允许产生这个类的一个实例，既然这么简单，就直接贴代码了。更详细的内容及说明可以参考原作者博客：cbf4life.cnblogs.com。3.1.解释main()，大臣CEmperor，需要单例的类说明：很多

http://www.cnblogs.com/nexiyi/archive/2013/06/16/3138568.html《极限编程》(Extreme programming)的指导原则之一是“只要能用，就做最简单的”。一个似乎需要继承的设计常常能够戏剧性地使用组合来代替而大简化，从而使其更加灵活。因此，在考虑一个设计时，问问自己：“使用组合是不是更简单？这里真的需要继承吗？它能带来什么好处？

http://www.cnblogs.com/robnetcn/archive/2012/04/15/2449008.html起因：模块独立性指每个模块只完成系统要求的独立子功能，并且与其他模块的联系最少且接口简单，两个定性的度量标准――耦合性和内聚性。    耦合性也称块间联系。指软件系统结构中各模块间相互联系紧密程度的一种度量。模块之间联系越紧密，其耦合性就越强，模块的独立性则越差

http://www.iteye.com/news/24488/面向对象设计原则是OOPS（Object-Oriented Programming System，面向对象的程序设计系统）编程的核心，但大多数Java程序员追逐像Singleton、Decorator、Observer这样的设计模式，而不重视面向对象的分析和设计。甚至还有经验丰富的Java程序员没有听说过OOPS和SOLID设

http://www.cnblogs.com/wanggary/archive/2011/04/07/2008796.html无意中，从网上下到一本电子书《24种设计模式介绍与6大设计原则》，很好奇这里有24种设计模式，印象中GOF写的《设计模式》（Design Patterns），好像只有23种吧。运行起来一看，还真挺吸引咱的，里面提到的例子都很有趣。很感谢作者写出这样好的例子来，我

http://www.youkuaiyun.com/article/2013-02-28/2814299-the-starcraft-path-finding-hack摘要：在之前的文章中，Warcraft之父讲述了自己是如何以及为何重启StarCraft的开发，在“离终止日期仅剩下两月”的压迫下，开发团队不得不做出了很多错误的决定，以至于带来了众多遗留问题。在本文中，Patrick讲述了其中一个难题——

http://www.cnblogs.com/leoo2sk/archive/2008/11/08/1329468.html摘要      本文以实例的方式，展示了如何使用UML进行面向对象的分析与设计。本文将假设读者对UML、面向对象等领域的基本内容已了然于胸，所以将不会过多阐述，而将重点放在应用过程上。本文的目的是通过一个完整的实例，展现基于UML的OOA&D过程的一个简化模式，帮

http://blog.jobbole.com/21088/前言：近来一段时间，忙于整理业务流程图，期间，关于流程图的绘制方法和工具也与内部团队和外部做了心得交流，恰好，个人生活也牵涉在买房，婚礼，户口迁移等流程中。不知不觉，伴随着实践与反思，个人所得的系统知识趋于完整，今儿天气极好，坐在飘窗一隅，听着间或几声鸟鸣歌唱，偶尔瞥一眼窗外的遍地绿荫，真真觉得是个写点什么的日子。所以就整理成文，

在并发编程中使用生产者和消费者模式能够解决绝大多数并发问题。该模式通过平衡生产线程和消费线程的工作能力来提高程序的整体处理数据的速度。为什么要使用生产者和消费者模式在线程世界里，生产者就是生产数据的线程，消费者就是消费数据的线程。在多线程开发当中，如果生产者处理速度很快，而消费者处理速度很慢，那么生产者就必须等待消费者处理完，才能继续生产数据。同样的道理，如果消费者的处理能力大于生