指尖思维

该三大原则应该算是OO的基础，很多OO设计原则和设计模式都是在此三大原则上面衍生发展而来。所以对于学习设计模式的人，了解这三大原则显然是非常必要的。 1．面向对象设计的第一原则：封装变化点。隔离变化点的好处在于，将系统中经常变化的部分和稳定的部分隔离，有助于增加复用性，并降低系统耦合度。很多设计模式的意图中都明显地指出了其对问题的解决方案，学习设计模式的要点是发现其解决

我们知道两个对象的关键关系是一个对象方法调用另一个对象方法的依赖关系，在这个关系中涉及四个部分：两个对象以及有调用依赖的两个方法，他们共同构成了元素模式的一个非常重要的概念——设计空间。我们这次所接触的几种EDP就产生自这个空间内。在一个类型实例方法调用另外一个类型实例的方法过程中，我们可以简单的总结如下内容。1.     对象之间的相似度2.     对象的类型之间的相似度3.

当我们在软件设计中想应用设计模式时，往往是凭借设计模式的名字和需求有点类似，之后就尝试着将模式生搬硬套到其中。而真正去理解设计模式往往变得比较困难，很多书籍也仅仅是用不同方法来降低模式记忆的强度。难道设计模式不能从更加细微的层面去理解吗？当然可以，设计模式就像可以再分解的化合物一般是可在分解，这种再分解后的模式叫做元素模式（elemental design patterns , EDP）。

整个项目分为BPM部分和Portal部分，期间都涉及到附件的上传、下载和删除。在BPM部分，附件永远是作为流程附件而存在的，故而这块的内容无论流程的多少，其可作为一种附件信息存入DB的一个Table，只是多了一个流程Id的标示即可，而旁的信息可以设置在各自的流程VWAttachment中（参见:http://blog.youkuaiyun.com/dongzi87/article/details/716367

 转载于：http://dotnet.blog.51cto.com/272325/51559 单点登录SSO（Single Sign-On）是身份管理中的一部分。SSO的一种较为通俗的定义是：SSO是指访问同一服务器不同应用中的受保护资源的同一用户，只需要登录一次，即 通过一个应用中的安全验证后，再访问其他应用中的受保护资源时，不再需要重新登录验证。 目前的企业应用环境中，

<br />这次在CollegeSystem建模后，经过了一次审定修改后，开始编写代码，编码过程中发现自己的设计不合理处很多。<br />类图画的不完善！自动生成代码时需要补充要调用的类。在此有个疑问，我们的类图中是不是应该将BLL层的类同DAL层的类画在一起呢？我想应该适时适当的画在一起，仍在探寻中。<br />时序图的不完善的方面是看我的时序图不能很清晰的从用户登录到将数据取回显示的真个时序过程。我想应该将某单一功能上的时序所涉及的类和主要方法及其调用关系在同一时序图中表述清楚。在先前的设计中，有的功能

行为型设计模式涉及的算法和对象间职责的分配。它不仅描述了对象或类的模式，还描述了它们之间的通信模式。这一点将在本总结中重点分析。那么首先看下各个行为型设计模式的含义。一、行为型设计模式的含义。1、观察者模式（Observer Pattern）定义了一种一对多的依赖关系，让多个对象同时关注同一主题。当这个主题对像的状态发生改变时，会通知这些观察者对象，使他们能够自动更新自己2、命令模

 有人说设计模式就是对设计原则的具体实现，将设计原则掌握好，了解透，对设计模式的理解与应用自然就会清晰了。不过想真的将这些原则了解的很透彻真的很难，在此先做下小小的整理与解析。渴望深层理解！一、设计原则的含义：1、单一职责原则：就一个类而言，应该仅有一个引起它变换的原因。2、开放封闭原则：软件实体（类，模块，方法等）可以扩展，但不应该修改。（）3、里氏代换原则：子类型必

    结构型设计模式涉及到如何组合类和对象以获得更大的结构。首先我问了自己一个问题：我为什么要获得更大的结构，不要这种大的结构不行吗？细想之下我发现其实这种大的结构不是我想不想要的问题，而是客观世界对我设计的软件需要这种或那种较大的不同类型的结构。那么客观世界中都有哪几种主要的结构要求呢，这些结构要求的实现可能有什么问题，我们怎么来解决呢？这些问题都将交给前人（愿意将经验分享给大家的人）的经

顾名思义创建型设计模式自然就与对象的产生有关了。而对类实例化为什么我们还要使用设计模式，而不是像往常在编程时用哪个类就直接实例化哪个类呢？这是因为我们在要考虑软件的灵活性，还有就是为满足一些即将被实例化的类的特殊要求。总之这种设计模式是解决类的实例化过程中遇到的问题的。 一、各个模式的含义1、工厂方法（Factory Method Pattern）：定义一个用于创建对象的接口，让子

     装饰模式就意图来讲是动态的给主体类增加功能，而这种功能的扩展比单独的使用子类来扩展灵活度更强。那么利用装饰模式比使用子类继承的灵活性在哪呢？      我们知道继承的重要作用之一便是可以对父类的既有的功能进行继承和扩展。但是如果对类A的功能采用继承方式进行扩展，那么这种扩展一旦写好就会在编译时固定下来，在运行期间就只会呈现出这一种功能特征。再有假如我们要给A扩展两种功能，且这两种功能

    在实现商场收费方式(策略)时,将个收费策略看成对象,使用简单工厂产生这些收费策略的对象的情况下与使用策略模式的不同点在于简单工厂生产这些策略对象时要进行判断,由于收费策略的异变性(变化点),所以在工厂类并未起到很好的封装变化点的作用,而且在客户端里仍需要实例化具体的收费策略类。而策略模式就很好的封装了变化点。    不过从策略模式的客户端代码来看,需要使用Switch Case语句,而

    在简单工厂改进了的抽象工厂中，DataAccess类返回的数据处理的接口类型，在DataAccess类中的Create事件中要实例化实现该借口的数据处理类。按照原先的由简单工厂改进后的抽象工厂模式，则必须要判断数据库类型，然后根据数据库类型实例化具体的数据处理类。这样就增加Select Case判断语句，这倒没什么，重要的我们想改变数据库时改动的地方会很多。如要从SQL Server改成A

    今天虽然没有看新课程，但今天很开心，原因有二，其一是给人带来了快乐，这个世界上其实每个人根本做不了太大的事情，给人带来快乐，你的功劳已是不少；其二则是我走上了改进学习方法的第一步！    虽然大话设计模式看完有一段时间了，虽然懂的不是那么透彻，但终究要知道个大体内容，才好做下一步学习，才好完善咱对设计模式的盲点不是！所以在此对设计模式做一下简短总结！首先我们要清楚，设计模式的应用只

Normal 0 7.8 磅 0 2 false false false MicrosoftInternetExplorer4 <! /* Style

<! /* Style Definitions */ table.MsoNormalTable {mso-style-name:普通表格; mso-tstyle-rowband-size:0; mso-tstyle-colband-size:0; mso-style-noshow:yes; mso-style-parent:""; mso-padding-al

环境Intel(R) Xeon(R) CPU E7-4850 v3 @ 2.20GHzCentOS release 6.4 (Final)2.6.32-358.el6.x86_6416335964 kB单机下多redis服务集群问题描述保存用户信息相应时间过长（11861ms）。其中调用service的save方法