When breaking apart responsibilities on a class this is enforcing Single Responsiblity Principle from SOLID. It’s an easy approach to apply this refactoring although it’s often disputed as what consitutes a “responsibility”. While I won’t be answering that here, I will show a clear cut example of a class that can be broken into several classes with specific responsibilities.
1: public class Video
2: {
3: public void PayFee(decimal fee)
4: {
5: }
6:
7: public void RentVideo(Video video, Customer customer)
8: {
9: customer.Videos.Add(video);
10: }
11:
12: public decimal CalculateBalance(Customer customer)
13: {
14: return customer.LateFees.Sum();
15: }
16: }
17:
18: public class Customer
19: {
20: public IList<decimal> LateFees { get; set; }
21: public IList<Video> Videos { get; set; }
22: }
As you can see here, the Video class has two responsibilities, once for handling video rentals, and another for managing how many rentals a customer has. We can break out the customer logic into it’s own class to help seperate the responsibilities.
1: public class Video
2: {
3: public void RentVideo(Video video, Customer customer)
4: {
5: customer.Videos.Add(video);
6: }
7: }
8:
9: public class Customer
10: {
11: public IList<decimal> LateFees { get; set; }
12: public IList<Video> Videos { get; set; }
13:
14: public void PayFee(decimal fee)
15: {
16: }
17:
18: public decimal CalculateBalance(Customer customer)
19: {
20: return customer.LateFees.Sum();
21: }
22: }
This is part of the 31 Days of Refactoring series. For a full list of Refactorings please see the original introductory post.
Posted
Aug 14 2009, 07:45 AM
by
schambers