摘要： 获取当前焦点所在的控件..Net本身没有该API.必须使用Win32 API解决.internal static extern IntPtr GetFocus();Control focusedControl = Control.FromHandle(GetFocus());判断控件是否含有焦点.Focused属性获取Control本身是否含有焦点.ContainsFocus属性用以判断Control本身以及其子控件是否含有焦点.Select()/Focus()方法在初始化时,如果想选中某个控件.在New()/Load事件中使用focus()是不可以的.因为控件还没有加载完毕.在New()/L 阅读全文

摘要： Command模式只是封装了一个没有任何变量的函数.interface Command{ void Excute();}具有强烈的分解功能的味道.把函数层面的任务提升到了类的层面(一个类仅仅是为了完成一个函数,而且没有该函数外的任何成员).简单的Command事件驱动的系统.Sensor(传感器).驱动者.只负责监听事件,并在事件发生后,调用绑定的Command的Excute方法.而不知道具体绑定的是什么样的Command.Command只负责执行具体的命令逻辑.两者的绑定关系可以定义于系统主体之外(xml文件etc.)事务操作.解除了 从用户获取数据,验证并操作数据,业务对象本身的耦合关系. 阅读全文

摘要： ISP用来处理fat接口的缺点.如果类的接口不是内聚的,那么该类就具有fat接口.fat接口可以分解为多个组.每个组服务于不同的客户.ISP承认不需要内聚接口的对象.但是建议客户不应该看到它作为单一的类而存在.客户程序看到的应该是多个具有内聚接口的抽象基类.接口污染.分离客户就是分离接口.客户对接口施加的反作用力.考虑引起变化的作用力时,通常考虑的是接口的变化会怎么影响它的使用者.但有时候,迫使接口改变的,正是它的使用者.ISP:不应该强迫客户依赖于它们不使用的方法.这样会导致所有客户程序间的耦合.一个客户依赖于一个它不使用的方法的类.但是其他客户却要使用该方法.此时,当其它客户要求这个类改变 阅读全文

摘要： 高层模块不应该依赖于底层模块，二者都应该依赖于抽象;细节应依赖于抽象.传统习惯中,高层模块依赖于底层模块,策略依赖于细节的结构.这是要定义子程序层次结构,该层次结构描述了高层模块如何调用底层模块.但是,这也就意味着,底层模块的更改会直接影响到高层模块.而APP的区别就是体现在这些高层模块中的.包含高层业务规则的模块应该优先并独立于包含细节的模块.通过子程序库来重用底层模块.我们更希望能够重用高层的策略设置模块.这也是Framework设计的核心.所以必须将高层独立于底层模块.倒置的接口所有权.底层实现了高层中声明并被高层调用的接口.这样高层可以在任何实现了该接口的环境中重用.有点短视的启发规则 阅读全文

摘要： OCP中,继承支持了抽象和多态特性.LSP:子类必须能够替换掉其基类.反例:使用if/else判断类型,以便选择针对特定类型的正确行为.有效性并非本质属性模型的有效性,只能通过它的客户程序来表现.在考虑一个特定设计是否合理时,必须要根据该设计的使用者所作出的合理假设来审视它.这些合理的假设常常就是单元测试中的assert.不要试图做所有的假设,而只是优先预测那些明显的对于LSP原则的违反情况,而在相关的脆弱性臭味出现时,才做其他的预测.IS-A是关于行为方式的.对象的行为方式才是软件所关注的.行为方式是可以进行合理假设的,是客户程序所依赖的.DBC:基于契约(Contract)设计.Class 阅读全文

摘要： 对于僵化性的臭味,应用OCP原则之后,再进行同样的改动时,只需添加新代码,而不必改动已正常运行的代码.扩展模块行为的方式通常是修改模块的Code,不允许修改的模块常常被认为是具有固定的行为.Open:模块的行为是可以扩展的,即可以改变模块的功能.Close:对模块进行扩展时,不必改动DLL,Code,lib等.封闭创建于抽象的基础之上.关键是抽象.抽象基类: 固定,能够描述一组任意个可能行为的抽象体.派生类: 一组任意个可能的行为的表现.模块操作抽象体.所以模块的依赖是一个固定(对修改封闭的)的抽象体.然后,通过从这个抽象体派生,可以扩展此模块的行为.该结构的问题:很可能会需要在switch中 阅读全文

摘要： 一个类应仅有一个引起它变化的原因.内聚性.每个Responsibility都是变化的一个轴线.当需求变化时,该变化会反映为类的职责的变化当一个类耦合了多个职责时,一个职责的变化会消弱或抑制其他职责的能力.这种耦合导致了fragile的设计.职责.A reson for change.一个类负担的N个职责是否应该分开.取决于APP变化的方式.如果程序变化总是导致N个职责同时变化,那么不必.而反之需要解耦这些职责.变化的轴线仅当实际发生时才有意义,在没有征兆时应用SRP或者其他原则都是不明智的.解耦职责后,肯定会有一个kludge杂凑物来耦合这些职责,但是除了main外,都不需要知道它的存在,所以 阅读全文

摘要： Agility,指以微小增量的方式构建软件.全局视图和软件一起演化.每次迭代中,都使设计尽可能适合于当前系统,而不会花时间去预测未来的需求,更不会试图构建一些基础结构去支撑未来才需要的特性.更关注的是当前的系统.不进行预先设计,不需要成熟的初始设计.而保持设计尽可能的干净,简单.并使用单元测试和验收测试来保证.需求处在不停变化的状态之中,如果设计由于需求变化而退化,那么就不是敏捷的.在实现新需求时,应改进原有设计以让设计对新变化的同类变化具有弹性.而不是设法给设计打补丁.敏捷设计是一个过程,而不是事件.Design,源代码就是设计,而UML图示只是设计的附属物而不是设计本身.设计中的臭味常常是 阅读全文

摘要： 静态视图对应用领域中的概念以及与系统实现有关的内部概念进行建模. 在OOP中,使用Class(广义的)来完成这些任务,所以,类和类的关系组成了静态视图.其亦称为类图. 核心:捕捉对象的结构.关联(asscociation):描述对象之间的链(关系).同一类的不同对象之间可以有关联,称为自反关联.多重性:一个类的多少个实例和另一端的类的实例相连.当多重性大于1时,可以指定关联值得排序和唯一性等说明.关联类:即时类又是关联的类.如果关联类的属性在一组关联对象中是唯一的,那么该属性称为限定符,这种关联称为限定关联(表和数组).限定符:对索引进行建模.用以从一组关联对象中标示出唯一对象的值.分析阶段. 阅读全文