Refactoring the next day: moving methods

Original Address: http://www.refactoring.com/catalog/moveMethod.html

In Class A, when a method is in use, or the functionality and resources that will be used are mostly present in another class B, rather than in Class A, then we need to consider moving this method to Class B.

To give an example:

1 classProject {2 person[] participants;3 }4 5 classPerson {6   intID;7 Boolean participate (Project p) {8      for(intI=0; i<p.participants.length; i++) {9       if(p.participants[i].id = = ID)return(true);Ten     } One     return(false); A   }    - } -  the...if(X.participate (p)) ...

In the example above, the participate method uses fields from the project class, so we decided to move the participate () method to the Project class.

After moving the participate method:

1 classProject {2 person[] participants;3 Boolean participate (Person X) {4      for(intI=0; i<participants.length; i++) {5       if(participants[i].id = = x.id)return(true);6     }7     return(false);8   }   9 }Ten  One classPerson { A   intID; - } -  the...if(P.participate (x)) ...

By doing so, the responsibilities of each class are made clearer and clearer.