Monthly Archives: November 2010

Notes on ‘Refactoring ‘ — 3.5 Replace subclass with Fields

Before Refactor

class Person{
   boolean isMale(){}

class Male extends Person{
   boolean isMale(){
       return true;

class Female extends Person{
   boolean isMale(){
       return false;

After Refactor

class Person{
   private boolean male;  
   private Person(male){
     this.male = male; 
   boolean isMale(){
     return male;
   Person createMale(){
      return new Person(true);
   Person createFemale(){
      return new Person(false);


Benefits: Avoid the complexity of subclassing

Notes on ‘Refactoring ‘ — 3.3 Encapsulate Collection

Before Re-factoring

class Person{
  Set courses; 
  Set getCourses(){
     return courses; 
  void setCourses(){...}

After Re-factoring

class Person{
  Set courses; 
  Set getCourses(){
    return Collections.unmodifiableSet(courses);
  void addCourse(){...}
  void removeCourse(){...}


Person will know it when
courses changes.

2. Coupling between clients which call
Person and
courses will be reduced.

Notes on ‘Refactoring ‘ — 3.1 Replace Data Value with Object

Before Refactoring

class Employee{
  String phoneNumber; 
     String area = phoneNumber.subString(...); 


class Employer{
  String phoneNumber; 
      String area = phoneNumber.subString(...); 

After refactoring

class Employee{
  Phone phoneNumber; 
     String area = phoneNumber.extractAreaCode(); 

class Employer{
  Phone phoneNumber; 
     String area = phoneNumber.extractAreaCode();

class Phone{
  String number; 
  String extractAreaCode(){

Notes on ‘Refactoring ‘ — 2.2 Replace Method with Method Object






Notes on ‘Refactoring ‘ — 1. Principals

1. Definition by Martin Fowler

   a.The purpose of refactoring is to
make the software easier to understand and modify

does not change the observable behavior of the software


2. Why Refactor? To make software easier to understand

      a. You can refactor it to make it more readable for future developers

      b. You can even refactor other’s code when trying to understand it

3. When to Refactor

   a. Don’t set aside time to do refactoring. Instead do refactoring only because you want to do something else better.

   b. So when?

      i. I’m adding a new feature and I need to understand the existing code.

      ii.I’m adding a new feature but existing code is hard for me to do that

      iii. We are doing code review and we received a suggestion. We refactor the code to implement the suggestion to see whether it works.

4. Problems of re-factoring

   a. DB is hard to refactor

   b. Changing Publised Interface is not Easy (Web Service Interface, etc.)

      i. In this case, provide the new method while retaining the old one (Deprecate it)

     ii. Try not to publish interfaces if not required     

5. Refactoring as an Alternative to Upfront Design

   a. Strict Upfront Design doesn’t work because problems usually show up when coding

   b. Programming and refactoring without any upfront design can work but it is not the most efficeint way

   c. The right way to go: Do some upfront design to have a plausible solution, then refactor

   d. Q: Shall I have a flexible solution for this feature? 

      A: What if I just have a simple solution here? If it is easy for me to refactor the simple solution to a flexible solution in the future, then we stick to the simple solution; Or else, we create a flexible version now.


6. Refactoring & Performance

    Refactoring may lead to slow software since it introduces more indirection, however, it makes the software easier to tune because it leads to finer granularity, which helps you find the exact hot spot.



第1章 敏捷——高效软件开发之道 

第2章 态度决定一切 

 1. 做事 

 2. 欲速则不达 

 3. 对事不对人 

 4. 排除万难,奋勇前进 

第3章 学无止境 

 5. 跟踪变化 

 6. 对团队投资 

 7. 懂得丢弃 

 8. 打破砂锅问到底 

 9. 把握开发节奏 

第4章 交付用户想要的软件 

 10. 让客户做决定 

 11. 让设计指导而不是操纵开发 

 12. 合理地使用技术 

 13. 保持可以发布 

 14. 提早集成,频繁集成 

 15. 提早实现自动化部署 

 16. 使用演示获得频繁反馈 

. 17. 使用短迭代,增量发布 

 18. 固定的价格就意味着背叛承诺 

第5章 敏捷反馈 

 19. 守护天使 

 20. 先用它再实现它 

 21. 不同环境,就有不同问题 

 22. 自动验收测试 

 23. 度量真实的进度 

 24. 倾听用户的声音 

第6章 敏捷编码 

 25. 代码要清晰地表达意图 

 26. 用代码沟通 

 27. 动态评估取舍 

 28. 增量式编程 

 29. 保持简单 

 30. 编写内聚的代码 

 31. 告知,不要询问 

 32. 根据契约进行替换 

第7章 敏捷调试 

 33. 记录问题解决日志 

 34. 警告就是错误 

 35. 对问题各个击破 

 36. 报告所有的异常 

 37. 提供有用的错误信息 

第8章 敏捷协作 

 38. 定期安排会面时间 

 39. 架构师必须写代码 

 40. 实行代码集体所有制 

 41. 成为指导者 

 42. 允许大家自己想办法 

 43. 准备好后再共享代码 

 44. 做代码复查 

 45. 及时通报进展与问题 

第9章 尾声:走向敏捷 

 9.1 只要一个新的习惯 

 9.2 拯救濒临失败的项目 

 9.3 引入敏捷:管理者指南 

 9.4 引入敏捷:程序员指南 

 9.5 结束了吗 

附录a 资源