代码改变世界

随笔档案-2010年06月

31 天重构学习笔记索引

2010-06-30 01:51 by 圣殿骑士, 22273 阅读, 收藏, 编辑
摘要： 由于最近在做重构的项目，所以对重构又重新进行了一遍学习和整理，对31天重构最早接触是在2009年10月份，由于当时没有订阅Sean Chambers的 blog，所以是在国外的社区上闲逛的时候链接过去的。记得当时一口气看完了整个系列并没有多少感觉，因为这些基本上项目都在使用，只是我们没有专门把它标示和整理出来，所以也没有引起多大的重视。现在突然接手这个重构项目，由于团队成员技术和经验参差不齐，所以有必要专门整理一个重构的纲要，当然这个系列也非常适合做新系统的代码规范参考，只要有代码的地方，这个重构规范就很有价值。 阅读全文

圣殿骑士博文索引

2010-06-30 01:14 by 圣殿骑士, 11847 阅读, 收藏, 编辑
摘要： 圣殿骑士很荣幸入住博客园和51CTO写技术博客，目前主要在一家外资企业从事项目管理、技术架构及企业技术培训工作。由于工作和项目需要，所以对一些技术进行了较为深入的研究，之前在整个公司做过一些技术专场的培训，由于每次时间较短且人员较多的关系，没能讲得很透彻，所以挺对不住那些同事的。现在在园子里开一个博客，希望能把所学的微薄知识书写出来，以供大家参考。近期将针对这些培训专场推出“OO到设计模式”、“WCF基础到企业应用”、“WPF基础到企业应用及优化”、 “Silverlight基础到企业应用及优化”、“Windows Azure基础到企业应用”等系列博文，由于是自己对这些技术的使用总结和心得体会，错误之处在所难免，所以希望大家能够多多指点，这样也能纠正我的错误观点，以便和各位共同提高！ 阅读全文

31天重构学习笔记31. 使用多态代替条件判断

2010-06-29 17:31 by 圣殿骑士, 5424 阅读, 收藏, 编辑
摘要： 本文中的”使用多态代替条件判断”是指如果你需要检查对象的类型或者根据类型执行一些操作时，一种很好的办法就是将算法封装到类中，并利用多态性进行抽象调用。”使用多态代替条件判断“这个重构在很多时候会出现设计模式中（常见的工厂家族、策略模式等都可以看到它的影子），因为运用它可以省去很多的条件判断，同时也能简化代码、规范类和对象之间的职责。 阅读全文

31天重构学习笔记30. 尽快返回

2010-06-29 16:33 by 圣殿骑士, 3378 阅读, 收藏, 编辑
摘要： 本文中的”尽快返回”是指把原来复杂的条件判断等语句用尽快返回的方式简化代码。这个重构很重要，它和前面讲的”分解复杂判断“有些类似，我们在做复杂的处理过程时，要经常考虑这个重构，用好了它，会对我们的帮助很大。 阅读全文

31天重构学习笔记29. 去除中间人对象

2010-06-29 16:13 by 圣殿骑士, 2845 阅读, 收藏, 编辑
摘要： 本文中的”去除中间人对象”是指把 在中间关联而不起任何其他作用的类移除，让有关系的两个类直接进行交互。 ”去除中间人对象“很多时候都会很有作用，尤其是在误用设计模式的代码中最容易见到，设计模式中的适配器模式和代理模式等都用中间的类是两者进行关联，这是比较合理的，因为中间类做了很多事情，而对于没有任何作用的中间类应该移除。 阅读全文

31天重构学习笔记28. 为布尔方法命名

2010-06-29 14:31 by 圣殿骑士, 3162 阅读, 收藏, 编辑
摘要： 本文中的”为布尔方法命名”是指如果一个方法带有大量的bool 参数时，可以根据bool 参数的数量，提取出若干个独立的方法来简化参数。”为布尔方法命名“这个重构在很多时候都不常用，如果用户的参数可枚举，我们一般会枚举它的值，不过使用这种重构也有好处，就是分解开来以后，方法多了，参数少了，代码维护起来方便了一些。 阅读全文

31天重构学习笔记27. 去除上帝类

2010-06-29 13:53 by 圣殿骑士, 4369 阅读, 收藏, 编辑
摘要： 本文中的”去除上帝类”是指把一个看似功能很强且很难维护的类，按照职责把自己的属性或方法分派到各自的类中或分解成功能明确的类，从而去掉上帝类。”去除上帝类“是我们经常容易造成的，第一是因为简便，看到有一个现成的类，大家都会喜欢把代码往里面写，最后导致越写越大，并且声明功能都有，这样即降低了可读性，也造成了维护的负担。 阅读全文

31天重构学习笔记26. 避免双重否定

2010-06-29 13:35 by 圣殿骑士, 2986 阅读, 收藏, 编辑
摘要： 本文中的”避免双重否定”是指把代码中的双重否定语句修改成简单的肯定语句，这样即让代码可读，同时也给维护带来了方便。”双重否定“很容易让人产生错误的判断，也很难让人理解你的代码，所以这个重构在我们的代码中是很重要的，尤其是在判断条件很多且业务复杂的时候。 阅读全文

31天重构学习笔记25. 引入契约式设计

2010-06-29 12:02 by 圣殿骑士, 3150 阅读, 收藏, 编辑
摘要： 本文中的”引入契约式设计”是指我们应该对应该对输入和输出进行验证，以确保系统不会出现我们所想象不到的异常和得不到我们想要的结果。微软在处理代码乃至产品的时候，很喜欢应用此重构，你如果认真看它的代码库，认真看一下WCF的设计，就不难发现了。这个重构建议大家经常使用，这会增强整个系统的稳定性和健壮性。 阅读全文

31天重构学习笔记24. 分解复杂判断

2010-06-29 10:45 by 圣殿骑士, 3487 阅读, 收藏, 编辑
摘要： 本文中的”分解复杂判断”是指把原来复杂的条件判断等语句用尽快返回等方式简化代码。这个重构很重要，它和后面讲的”尽快返回“有些类似，我们在做复杂的处理过程时，要经常考虑这个重构，用好了它，会对我们的帮助很大。 阅读全文

31天重构学习笔记23. 引入参数对象

2010-06-29 10:20 by 圣殿骑士, 2866 阅读, 收藏, 编辑
摘要： 本文中的“引入参数对象”是指当一个方法的参数过多或者过为复杂时，可以考虑把这些参数封装成一个单独的类，这种重构很重要，尤其是当一个方法的参数比较多的时候，不管是大中型项目还是小型项目，都会遇到这种场景，所以建议大家多使用这个重构。这种封装的思想在 SOA 里面也经常运用到，封装输入Message，封装输出Message，消息来和消息去以及消息间的交互就构成了整个应用体系。 阅读全文

31天重构学习笔记22. 分解方法

2010-06-29 09:58 by 圣殿骑士, 2595 阅读, 收藏, 编辑
摘要： 本文中的”分解方法”是指把我们所做的这个功能不停的分解方法，直到将一个大方法分解为名字有意义且可读性更好的若干个小方法。其实这个重构和我们前面讲的“提取方法”和“提取方法对象”如出一辙，尤其是“提取方法”，所以大家只要知道用这种思想重构就行。 阅读全文

31天重构学习笔记21. 合并继承

2010-06-29 09:46 by 圣殿骑士, 2681 阅读, 收藏, 编辑
摘要： 本文中的”合并继承”是指如果子类的属性和方法也适合于基类，那么就可以移除子类，从而减少依赖关系。这篇和上篇其实最主要论述了子类和父类的继承关系以及如何判断什么时候需要使用继承，一般我们都能处理好这些关系，所以相对比较简单。 阅读全文

31天重构学习笔记20. 提取子类

2010-06-28 22:32 by 圣殿骑士, 2639 阅读, 收藏, 编辑
摘要： 本文中的”提取子类”是指把基类中的一些不是所有子类都需要访问的方法调整到子类中。这个重构方法经常用来规范类的职责，和之前的一些重构方法也有些类似。 阅读全文

31天重构学习笔记19. 提取工厂类

2010-06-28 18:32 by 圣殿骑士, 3920 阅读, 收藏, 编辑
摘要： 本文中的“提取工厂类”是指如果要创建的对象很多，则代码会变的很复杂。一种很好的方法就是提取工厂类。这个重构经常会在项目中使用，如果要创建的对象是一个，你可以采用简单工厂，但是这种方式还是会存在很多依赖，维护起来也比较不方便。所以推荐使用工厂方法模式，把实例化延迟到子类。如果你要创建一系列的对象，那么就推荐你使用抽象工厂模式，但是要注意不要过度设计，只要能满足不断变化的需求和给以后的维护和重构带来方便即可。 阅读全文

31天重构学习笔记18. 使用条件判断代替异常

2010-06-28 18:12 by 圣殿骑士, 3309 阅读, 收藏, 编辑
摘要： 本文中的“使用条件判断代替异常”是指把没有必要使用异常做判断的条件尽量改为条件判断。这个重构在项目代码中也经常用到，因为对于一部分程序员，是很难把握什么时候用try catch ，什么地方该用try catch 。记得之前大家还专门讨论过这些，比如如何用好以及在大中型项目中应该把它放在哪一个组件中等。 阅读全文

31天重构学习笔记17. 提取父类

2010-06-28 15:53 by 圣殿骑士, 2783 阅读, 收藏, 编辑
摘要： 本文中的“提取父类”是指类中有一些字段或方法，你想把它们提取到父类中以便同一继承层次的其它类也可以访问他们，这个和之前的很多重构有异曲同工之处。这个重构是典型的继承用法，很多程序员都会选择这样做，但是要注意正确的使用，不要造成过度使用了继承，如果过度使用了，请考虑用接口、组合和聚合来实现。 阅读全文

31天重构学习笔记16. 封装条件

2010-06-28 15:38 by 圣殿骑士, 3079 阅读, 收藏, 编辑
摘要： 本文中的“封装条件”是指条件关系比较复杂时，代码的可读性会比较差，所以这时我们应当根据条件表达式是否需要参数将条件表达式提取成可读性更好的属性或者方法，如果条件表达式不需要参数则可以提取成属性，如果条件表达式需要参数则可以提取成方法。这个重构在很大程度上能改善代码的可读性，尤其是在一个逻辑很复杂的应用中，把这些条件判断封装成一个有意义的名字，这样很复杂的逻辑也会立刻变得简单起来。 阅读全文

31天重构学习笔记15. 移除重复内容

2010-06-28 15:26 by 圣殿骑士, 2715 阅读, 收藏, 编辑
摘要： 本文中的“移除重复内容”是指把一些很多地方都用到的逻辑提炼出来，然后提供给调用者统一调用。这个重构很简单，绝大多数程序员都会使用这种重构方法，但有时由于习惯、时间、赶进度等原因而忽略它，所以会使得整个系统杂乱无章，到处都是Ctrl+C和Ctrl+V的痕迹。 阅读全文

31天重构学习笔记14. 分离职责

2010-06-28 15:14 by 圣殿骑士, 3275 阅读, 收藏, 编辑
摘要： 本文中的“分离职责”是指当一个类有许多职责时，将部分职责分离到独立的类中，这样也符合面向对象的五大特征之一的单一职责原则，同时也可以使代码的结构更加清晰，维护性更高。这个重构经常会用到，它和之前的“移动方法”有几分相似之处，让方法放在合适的类中，并且简化类的职责，同时这也是面向对象五大原则之一和设计模式中的重要思想。 阅读全文

31天重构学习笔记13. 提取方法对象

2010-06-28 15:01 by 圣殿骑士, 3011 阅读, 收藏, 编辑
摘要： 本文中的“提取方法对象”是指当你发现一个方法中存在过多的局部变量时，你可以通过使用“提取方法对象”重构来引入一些方法，每个方法完成任务的一个步骤，这样可以使得程序变得更具有可读性。本文的重构方法在有的时候还是比较有用，但这样会造成字段的增加，同时也会带来一些维护的不便，它和“提取方法”最大的区别就是一个通过方法返回需要的数据，另一个则是通过字段来存储方法的结果值，所以在很大程度上我们都会选择“提取方法”。 阅读全文

31天重构学习笔记12. 分解依赖

2010-06-28 14:44 by 圣殿骑士, 3663 阅读, 收藏, 编辑
摘要： 本文中的“分解依赖” 是指对部分不满足我们要求的类和方法进行依赖分解，通过装饰器来达到我们需要的功能。这个重构在很多时候和设计模式中的一些思想类似，使用中间的装饰接口来分解两个类之间的依赖，对类进行装饰，然后使它满足我们所需要的功能。 阅读全文

31天重构学习笔记11. 使用策略类

2010-06-28 14:24 by 圣殿骑士, 4932 阅读, 收藏, 编辑
摘要： 本文中的“使用策略类” 是指用设计模式中的策略模式来替换原来的switch case和if else语句，这样可以解开耦合，同时也使维护性和系统的可扩展性大大增强。这种重构在设计模式当中把它单独取了一个名字——策略模式，这样做的好处就是可以隔开耦合，以注入的形式实现功能，这使增加功能变得更加容易和简便，同样也增强了整个系统的稳定性和健壮性。 阅读全文

31天重构学习笔记10. 提取方法

2010-06-28 13:43 by 圣殿骑士, 3497 阅读, 收藏, 编辑
摘要： 本文中的把某些计算复杂的过程按照功能提取成各个小方法，这样就可以使代码的可读性、维护性得到提高。这个重构在很多公司都有一些的代码规范作为参考，比如一个类不能超过多少行代码，一个方法里面不能超过多少行代码，这在一定程度上也能使程序员把这些复杂的逻辑剥离成意义很清楚的小方法。 阅读全文

31天重构学习笔记9. 提取接口

2010-06-28 12:31 by 圣殿骑士, 3999 阅读, 收藏, 编辑
摘要： 本文中的“提取接口” 是指超过一个的类要使用某一个类中部分方法时，我们应该解开它们之间的依赖，让调用者使用接口，这很容易实现也可以降低代码的耦合性。这个重构策略也是一个常见的运用，很多设计模式也会在其中运用此思想（如简单工程、抽象工厂等都会通过接口来解开依赖）。 阅读全文

31天重构学习笔记8. 使用委派代替继承

2010-06-28 12:16 by 圣殿骑士, 4419 阅读, 收藏, 编辑
摘要： 本文中的“使用委派代替继承”是指在根本没有父子关系的类中使用继承是不合理的，可以用委派的方式来代替。这个重构是一个很好的重构，在很大程度上解决了滥用继承的情况，很多设计模式也用到了这种思想（比如桥接模式、适配器模式、策略模式等）。 阅读全文

31天重构学习笔记7. 重命名（方法，类，参数）

2010-06-28 12:00 by 圣殿骑士, 3844 阅读, 收藏, 编辑
摘要： 本文中的改名（方法，类，参数）是指在写代码的时候对类、方法、参数、委托、事件等等元素取一个有意义的名称。此重构经常被广大程序员所忽视，但是带来的隐患是不可估量的，也许老板要修改功能，那我们来看这段没有重构的代码（就算是自己写的，但由于时间和项目多等关系，我们也很难理解了），然后就会变得焦头烂额。相反重构后的代码就会觉得一目了然、赏心悦目。 阅读全文

31天重构学习笔记6. 降低字段

2010-06-28 11:49 by 圣殿骑士, 3189 阅读, 收藏, 编辑
摘要： 本文中的降低字段和前篇的提升字段正好相反，就是把基类中只有某些少数类用到的字段降低到使用它们的子类中。 此重构也是一个非常简单的重构，在很多时候我们都会不自觉的使用它。 阅读全文

31天重构学习笔记5. 提升字段

2010-06-28 11:41 by 圣殿骑士, 3634 阅读, 收藏, 编辑
摘要： 本文中的提升字段和前面的提升方法颇为相似，就是把子类公用的字段提升到基类中，从而达到公用的目的。这个重构的策略比较简单，同时也是比较常用的一些做法，最主要就是要注意权衡是否真的有这个必要，看这样做究竟有没有什么好处（比如只需要改一个地方，维护简便了，同时代码量也更少了等）。 阅读全文

31天重构学习笔记4. 降低方法

2010-06-28 11:31 by 圣殿骑士, 3870 阅读, 收藏, 编辑
摘要： 本文中的降低方法和前篇的提升方法整好相反，也就是把个别子类使用到的方法从基类移到子类里面去。面向对象三大特征（继承、封装、多态）很多时候可以帮助我们，但同时也可能会造成使用过度或者使用不当，所以如何把握好设计，这个就变得至关重要。在什么时候使用继承的方式，在什么时候使用组合和聚合，接口和继承类的选择等久成了我们的重点。 阅读全文

31天重构学习笔记3. 提升方法

2010-06-28 03:52 by 圣殿骑士, 5079 阅读, 收藏, 编辑
摘要： 提升方法是指将一个很多继承类都要用到的方法提升到基类中。这个重构要根据具体情况使用，如果不是每个子类都有这个方法的话，可以考虑使用接口或者其他方式。 阅读全文

31天重构学习笔记2. 移动方法

2010-06-28 03:49 by 圣殿骑士, 6697 阅读, 收藏, 编辑
摘要： 本文所讲的移动方法就是方法放在合适的位置（通常指放在合适的类中）。这个重构法则在很多时候能让我们把代码组织的结构调整得更合理，同时也能给以后的维护带来方便。 阅读全文

31天重构学习笔记1. 封装集合

2010-06-28 03:46 by 圣殿骑士, 15061 阅读, 收藏, 编辑
摘要： 本文所讲的封装集合就是把集合进行封装，只提供调用端需要的接口。这个例子很容易让我们想到以前系统间耦合常喜欢用数据库。每个系统都会操作数据库，并且有些系统还会对数据库的表结构或字段进行修改，那么这很容易就会造成维护的地狱，很明智的一个做法就是使用SOA来隔开这些耦合，让一些只需要数据展示的系统得到自己需要的数据即可。 阅读全文

.NET 技术社区谈之英文篇

2010-06-26 17:15 by 圣殿骑士, 5788 阅读, 收藏, 编辑
摘要： 前言：由于这几年一直专注于.NET的技术开发、管理和架构。所以很多时候都会关注一些社区和网站，但自己由于时间有限，或者是因为人懒，一直没有时间为社区做出贡献，偶感惭愧。几年下来对.NET也逐渐形成了自己的一套知识库，这要感谢这些技术社区，故而有此文诞生。文中的评价实属我（圣殿骑士）个人意见，如有不妥，还请多多见谅。如果想了解中文的.net技术社区，也可以参考.NET 技术社区之我见（中文篇）自己根... 阅读全文

.NET 技术社区谈之中文篇

2010-06-26 13:56 by 圣殿骑士, 5622 阅读, 收藏, 编辑
摘要： 前言：由于这几年一直专注于.NET的技术开发、管理和架构。所以很多时候都会关注一些社区和网站，但自己由于时间有限，或者是因为人懒，一直没有时间为社区做出贡献，偶感惭愧。几年下来对.NET也逐渐形成了自己的一套知识库，这要感谢这些技术社区，故而有此文诞生。文中的评价实属我（圣殿骑士）个人意见，如有不妥，还请多多见谅。如果想了解中文的.net技术社区，也可以参考.NET 技术社区之我见（英文篇）。描述... 阅读全文

项目重构方案设计

2010-06-23 11:28 by 圣殿骑士, 14043 阅读, 收藏, 编辑
摘要： 最近接手到一个已经成型的项目，然后我们的任务就是对它进行重构，这个项目是一个功能很齐全的WPF视频播放器（附带很多其他功能），在仔细研究了项目的背景和架构以后，初步做出了一下的重构方案：目前现状：虽然整个系统做得很漂亮，代码也写得不错，但仍有以下不足：架构有待改善。虽然看似MVC架构，却没有遵循MVC的模式，里面逻辑和UI耦合很高，没有清晰的规律。没有充分用到WPF的特性。WPF除了给我们很多炫丽的效果外，还给我们提供了诸如Binding,command等特性，这些特性可以帮我们隔开耦合，同时减少代码量。代码和文件没有组织。代码、dll、样式文件和资源文件等没有统一的组织，到处都有，这样看.. 阅读全文
点击右上角即可分享
微信分享提示