1.常规switch enum EnumType { enumOne, enumTwo, enumThree }; void showMessage(int type) { switch(type) { case enumOne: printf("This is message one\n"); break; case enumTwo: printf("This is message two\n"); break; case enumThree: printf(&q

public class Fun{ public void IFNumberid(int flag) { switch (flag) { : Console.WriteLine("优秀"); break; : Console.WriteLine("良好"); break; : Console.WriteLine("一般"); break; : Console.WriteLine("不及格"); break; default:

理解:策略就是平常设计模式中所说的策略模式.因为当你有一个庞大的switch方法的时候,每一次新加一个条件,都要去修改这个方法,这样耦合性太高,不易维护也不易扩展.这样我们就可以使用策略的设计模式,使得每一种情况都封装在自己的类中,来提高扩展性和降低耦合性. 详解: using System; using System.Collections.Generic; using System.Linq; using System.Text; namespace _31DaysRefactor { pu

3. 运用多态取代与价格相关的条件逻辑 3.1 switch和“常客积分”代码的再次搬迁 (1)switch:最好不要在另一个对象的属性上运用switch语句 switch(getMovie().getPriceCode()) //在movie对象的priceCode属性上运用switch { //这意味着可以将getCharge函数从Rental类移动到Movie类去 //选择在Movie类中封装计算费用功能,还有一个 //原因,就是可以控制因影片类型变化导致的计算 //方式变化,从而对其它对

我们在开发asp.net时,经常有使用if...else...或者是使用switch来进行多个条件判断.如下面这篇<用户控件(UserControl) 使用事件 Ver2>http://www.cnblogs.com/insus/archive/2011/11/18/2253605.html,就是一段代码: 其实按上面的写法一点问题都没有,但是我们在审检代码看到这段代码时似乎要花点时间阅读,用意也不够明朗,藕合性也高. 建议把每个case块写成一个独立的方法.然后再调用它,目的是为最小化方法.

重构没有固定的形式,多年来我使用过不同的版本,并且我敢打赌不同的人也会有不同的版本. 该重构适用于这样的场景:switch语句块很大,并且会随时引入新的判断条件.这时,最好使用策略模式将每个条件封装到单独的类中.实现策略模式的方式是很多的.我在这里介绍的策略重构使用的是字典策略,这么做的好处是调用者不必修改原来的代码. public class ClientCode { public double CalculateShipping() { ShippingInfo shippingInfo =

http://www.cnblogs.com/insus/p/4142264.html 重构if...else...或者switch程序块 为 中介者(Mediator)模式.的思考 首先普世的编程架构好坏评判是SOLID(单一功能.开闭原则.里氏替换.接口隔离以及依赖反转) 具体来说,就是当有需求的curd时候,代码应该1)涉及的文件尽可能的少2)修改的文件行数尽可能的少3)修改的文件行块间距不应该太长,避免程序员在一个文件中来回移动.鼠标点击数尽可能少.避免影响思路.4)不应该影响其他模块的

软件重构是改善代码可读性.可扩展性.可维护性等目的的常见技术手段.圈复杂度作为一项软件质量度量指标,能从一定程度上反映这些内部质量需求(当然并不是全部),所以圈复杂度往往被很多项目采用作为软件质量的度量指标之一. C语言开发的项目中,switch/case代码块是一个很容易造成圈复杂度超标的语言特性,所以本文主要介绍下降低switch/case圈复杂度的重构方法(如下图).switch圈复杂度优化重构可分为两部分:程序块的重构和case的重构.程序块重构是对代码的局部优化,而case重构是对代码

switch作为条件判断(分支结构)中的一种方式,以至于我们对于它使用的频率处于较高水平的水平线上,为此我们应该使用Extra method来对这类判断条件进行抽取,另外从我自身而言,我发现我以前常常在当中根据不同的值,做不同的操作,而这类操作我是直接写在case里面的!而这里<重构>的作者并没有明确的讲明这样做的好处到底在哪里?我们现在就拿我们前一篇文章来作接下来的讲解. 没有看过前一篇文章的,点击这里带你看哦 现在我们模拟一个场景,作为项目经理的老王,告诉程序员小新说:现在我们的影片类型需

在代码中,时常有就一类型码(Type Code)而展开的如 switch ... case 或 if ... else if ... else 的条件表达式.随着项目业务逻辑的增加及代码经年累月的修改,这些条件判断逻辑往往变得越来越冗长.特别是当同样的逻辑判断出现在多个地方的时候(结构示意如下),代码的可读性和维护难易程度将变得非常的糟糕.每次修改时,你必须找到所有有逻辑分支的地方,并修改它们. switch(type) { ": ... break; ": ... break; ca

最近几天,在进行重构的时候,遇到了一个极其丑陋的代码(自己写的 /捂脸  当时时间紧,于是....),今天去重构的时候无论如何也想不出方法,去除这个丑陋的switch语句 ,于是写篇博客,让自己记住这个问题 . switch (status) { : return View("Create", applyBlog); : return View(); : return View("PersonalBlogPage"); : return View("Cre

目录 1.背景 2.案例 3.switch…case…方式实现 4.switch…case…带来的问题 5.使用策略模式重构switch…case…代码 6.总结 1.背景 之前在看<重构    改善既有代码的设计>一书,在看到Replace Type Code With  State/Strategy(用状态模式/策略模式替换类型码)一节时遇到一个困惑:怎么用策略模式替换switch case代码?所幸的时,两天前查资料的时候偶然看到 圣殿骑士 的博客,他写的<31天重构学习>系

http://bj007.blog.51cto.com/1701577/345100/ switch语句是我们日常工作中最常见也是争论最多的(goto被忽视的前提下).在重构中也把switch语句看成是一种代码的坏味道.但如何改造现有的switch代码并在今后去避免呢?本文从两方面进行探讨. 1 类型转化     在不同的抽象层次上对于同一个对象可能会用不同的定义.举个简单的例子,在计算器中,用户输入的操作符号可能是字符型的,而程序内部实现的时候需要用枚举型.因此可能就会有这样的函数.     

面相对象的一个核心基础就是多态,当你要根据对象类型的不同要做不同的操作的时候,一个好的办法就是采用多态,把算法封装到子类当中去. 重构前代码: public abstract class Customer { } public class Employee : Customer { } public class NonEmployee : Customer { } public class OrderProcessor { public decimal ProcessOrder(Customer

坏味道--Switch声明(Switch Statements) 特征 你有一个复杂的 switch 语句或 if 序列语句. 问题原因 面向对象程序的一个最明显特征就是:少用 switch  和 case 语句.从本质上说,switch 语句的问题在于重复(if 序列也同样如此).你常会发现 switch 语句散布于不同地点.如果要为它添加一个新的 case 子句,就必须找到所有 switch 语句并修改它们.面向对象中的多态概念可为此带来优雅的解决办法. 大多数时候,一看到 switch 语

OSharp是什么? OSharp是个快速开发框架,但不是一个大而全的包罗万象的框架,严格的说,OSharp中什么都没有实现.与其他大而全的框架最大的不同点,就是OSharp只做抽象封装,不做实现.依赖注入.ORM.对象映射.日志.缓存等等功能,都只定义了一套最基础最通用的抽象封装,提供了一套统一的API.约定与规则,并定义了部分执行流程,主要是让项目在一定的规范下进行开发.所有的功能实现端,都是通过现有的成熟的第三方组件来实现的,除了EntityFramework之外,所有的第三方实现都可以轻

前言 Rafy 领域实体框架作为一个使用领域驱动设计作为指导思想的开发框架,必然要处理领域实体到数据库表之间的映射,即包含了 ORM 的功能.由于在 09 年最初设计时,ORM 部分的设计并不是最重要的部分,那里 Rafy 的核心是产品线工程.模型驱动开发.界面生成等.所以当时,我们简单地采用了一个开源的小型 ORM 框架:<Lite ORM Library>.这个 ORM 框架可以生成比较简单的 Sql 语句,以处理一般性的情况. 随着不断使用,我们也不断对 ORM 的源码做了不少改动,让它

原文地址: PHP 杂谈<重构-改善既有代码的设计>之一 重新组织你的函数 思维导图   点击下图,可以看大图.    介绍   我把我比较喜欢的和比较关注的地方写下来和大家分享.上次我写了篇<php 跟老大的对话>.还是有很多疑问,这书帮了我不少的忙.   如果你比较繁忙,或者懒得看文字,建议你直接看截图,也会有很大的收获的.你可以通过比较截图中的代码就能知道孰优孰劣了.   代码部分我为什么用图呢?因为我经常用手机看代码,博客园的代码在手机里乱七八糟的,还是看图比较舒服.  

前言 RAC相比以往的开发模式主要有以下优点:提供了统一的消息传递机制:提供了多种奇妙且高效的信号操作方法:配合MVVM设计模式和RAC宏绑定减少多端依赖. RAC的理论知识非常深厚,包含有FRP,高阶函数,冷信号与热信号,RAC Operation,信号的生命周期等,这些文档里都有介绍. 但是由于RAC本身的特性,可能会听上去容易上手难. 本文还是从一个比较接地气的角度开始的.因为现在要做一个完美100%的全项目ReactiveCocoa架构基本不太现实,大多数项目都会有很多历史包袱,我们只能

第一章 ☛过度设计:是指代码的灵活性和复杂性超出所需. 第二章 ☛重构是一种保持行为的转换. 第三章 ☛每一个模式都是由三部分组成的规则,他表达的是某一环境,一个问题以及解决问题的方案之间的关系. ☛模式痴迷:对模式过于依赖. 第四章 ☛代码坏味道 ●代码重复(Duplicated Code) 通常可以通过形成Template Method重构. ●方法过长(Long Method) ●条件逻辑太复杂(Conditional Complexity) ●基本类型迷恋(Primitive Obses

2. 分解并重组statement (1)提炼switch语句到独立函数(amountFor)和注意事项. ①先找出函数内的局部变量和参数:each和thisAmount,前者在switch语句内未被修改,后者会被修改. ②任何不会被修改的变量都可以当成参数传入新的函数,如将each为作为参数传给amountFor()的形参. ③至于会被修改的变量要格外小心,如果只有一个变量会被修改(如thisAmount),则可以当作新函数的返回值. [实例分析]影片出租2 //顾客类(用来表示顾客) cla