上一页 1 ··· 20 21 22 23 24 25 26 27 28 ··· 37 下一页
摘要: 1. 确保没有任何警告(warnings)。2.如果先执行Code Analysis(启用所有Microsoft Rules)再消除所有警告就更好了。3.去掉所有没有用到的usings。编码过程中去掉多余代码是个好习惯。(参考:msdn)4. 在合理的地方检查对象是否为’null’,避免运行的时候出现Null Reference Exception。5. 始终遵循命名规范。一般而言变量参数使用驼峰命名法,方法名和类名使用Pascal命名法。(参考:msdn)6. 请确保你了解SOLID原则。根据维基百科定义:在程序设计领域,SOLID(单一功能、开闭原则、里氏替换、接口隔离以及依赖反转)是由罗 阅读全文
posted @ 2013-08-22 11:45 幕三少 阅读(1677) 评论(4) 推荐(5) 编辑
摘要: 一、ISP简介(ISP--Interface Segregation Principle):使用多个专门的接口比使用单一的总接口要好。一个类对另外一个类的依赖性应当是建立在最小的接口上的。一个接口代表一个角色,不应当将不同的角色都交给一个接口。没有关系的接口合并在一起,形成一个臃肿的大接口,这是对角色和接口的污染。“不应该强迫客户依赖于它们不用的方法。接口属于客户,不属于它所在的类层次结构。”这个说得很明白了,再通俗点说,不要强迫客户使用它们不用的方法,如果强迫用户使用它们不使用的方法,那么这些客户就会面临由于这些不使用的方法的改变所带来的改变。二、举例说明:参考下图的设计,在这个设计里,取款 阅读全文
posted @ 2013-08-21 16:55 幕三少 阅读(808) 评论(1) 推荐(1) 编辑
摘要: /// /// 备注特性 /// public class RemarkAttribute : Attribute { /// /// 备注 /// public string Remark { get; set; } public RemarkAttribute(string remark) { this.Remark = remark; } } /// /// 枚举扩展类 /// public stat... 阅读全文
posted @ 2013-08-21 16:55 幕三少 阅读(1777) 评论(0) 推荐(0) 编辑
摘要: 上一章我们讲了构造注入与设值注入,这一篇我们主要讲接口注入与特性注入。 接口注入 接口注入是将抽象类型的入口以方法定义在一个接口中,如果客户类型需要获得这个方法,就需要以实现这个接口的方式完成注入。实际上接口注入有很强的侵入性,除了要求客户类型增加前面两种方式所需要的代码外,还必须显示地定义一个新的接口并要求客户类型实现它。 //定义需要注入ITimeProvider的类型... 阅读全文
posted @ 2013-08-21 08:26 幕三少 阅读(2681) 评论(0) 推荐(1) 编辑
摘要: 在项目中增加两张图片Content.jpg和Resource.jpg,分别将其生成操作属性设置为Content和Resource。在界面中增加两个Image控件ImgContent和ImgResource,在XAML中分别设置Source路径为Content.jpg和Resource.jpg。运行后ImgResource能正常显示图片,但是ImgContent控件无显示。将Content.jpg图片拷贝至应用程序的Debug目录中,ImgContent控件可显示图片。生成操作设置为Resource,生成的时候资源将添加到程序集中。可以尝试将原有的图片删除,图片正常显示。将原有图片用新图片替换, 阅读全文
posted @ 2013-08-20 15:08 幕三少 阅读(1933) 评论(2) 推荐(1) 编辑
摘要: 背景介绍 在设计模式中,尤其是结构型模式很多时候解决的就是对象间的依赖关系,变依赖具体为依赖抽象。平时开发中如果发现客户程序依赖某个或某类对象,我们常常会对他们进行一次抽象,形成抽象的抽象类、接口,这样客户程序就可以摆脱所依赖的具体类型。 这个过程中有个环节被忽略了 谁来选择客户程序需要的满足抽象类 阅读全文
posted @ 2013-08-20 09:22 幕三少 阅读(2469) 评论(9) 推荐(5) 编辑
摘要: 一、LSP简介(LSP--Liskov Substitution Principle):定义:如果对于类型S的每一个对象o1,都有一个类型T的对象o2,使对于任意用类型T定义的程序P,将o2替换为o1,P的行为保持不变,则称S为T的一个子类型。子类型必须能够替换它的基类型。LSP又称里氏替换原则。对于这个原则,通俗一些的理解就是,父类的方法都要在子类中实现或者重写。二、举例说明:对于依赖倒置原则,说的是父类不能依赖子类,它们都要依赖抽象类。这种依赖是我们实现代码扩展和运行期内绑定(多态)的基础。因为一旦类的使用者依赖某个具体的类,那么对该依赖的扩展就无从谈起;而依赖某个抽象类,则只要实现了该抽 阅读全文
posted @ 2013-08-19 13:37 幕三少 阅读(810) 评论(2) 推荐(0) 编辑
摘要: 一、DIP简介(DIP--Dependency InversionPrinciple):1、高层模块不应该依赖于低层模块,二者都应该依赖于抽象。2、抽象不应该依赖于细节,细节应该依赖于抽象。高层模块包含了一个应该程序中的重要的策略选择和业务模型,正是这些高层模块才使得其所有的应用程序区别于其他,如果高层依赖于低层,那么对低层模块的改动就会直接影响到高层模块,从而迫使它们依次做出改动。二、举例说明:反面例子:缺点:耦合太紧密,Light发生变化将影响ToggleSwitch。解决办法一:将Light作成Abstract,然后具体类继承自Light。优点:ToggleSwitch依赖于抽象类Lig 阅读全文
posted @ 2013-08-18 14:15 幕三少 阅读(401) 评论(0) 推荐(0) 编辑
摘要: 一、OCP简介(OCP--Open-Closed Principle):Software entities(classes,modules,functions,etc.) should be open for extension, but closed for modification。软件实体应当对扩展开放,对修改关闭,即软件实体应当在不修改(在.Net当中可能通过代理模式来达到这个目的)的前提下扩展。Open for extension:当新需求出现的时候,可以通过扩展现有模型达到目的。 Close for modification:对已有的二进制代码,如dll,jar等,则不允许做任.. 阅读全文
posted @ 2013-08-18 14:08 幕三少 阅读(485) 评论(0) 推荐(0) 编辑
摘要: 一、SRP简介(SRP--Single-Responsibility Principle):就一个类而言,应该只专注于做一件事和仅有一个引起它变化的原因。所谓职责,我们可以理解他为功能,就是设计的这个类功能应该只有一个,而不是两个或更多。也可以理解为引用变化的原因,当你发现有两个变化会要求我们修改这个类,那么你就要考虑撤分这个类了。因为职责是变化的一个轴线,当需求变化时,该变化会反映类的职责的变化。“就像一个人身兼数职,而这些事情相互关联不大,,甚至有冲突,那他就无法很好的解决这些职责,应该分到不同的人身上去做才对。”二、举例说明:违反SRP原则代码:modem接口明显具有两个职责:连接管理和 阅读全文
posted @ 2013-08-18 14:04 幕三少 阅读(475) 评论(0) 推荐(0) 编辑
上一页 1 ··· 20 21 22 23 24 25 26 27 28 ··· 37 下一页