Comments on: Refactoring Day 14 : Break Responsibilities

By: schambers

schambers — Wed, 11 Nov 2009 13:02:39 +0000

@Robert the example is a bit contrived so the two other comment posters are partially correct. You can just pass this to the videos.add(this) method, although I don’t agree that you should move the RentVideo method to the Customer object. That violates single responsibility principle in the fact that now the customer is in charge of maintaining account balance AND renting videos which is a mix of responsiblities.

I’m not sure how this makes it more confusing. It’s simply applying the single responsibility principle. When you start to get more than one reason for a class to change it has too many responsibilities and should be broken up into more distinct classes.

Does that make sense?

By: Robert

Robert — Wed, 11 Nov 2009 09:05:18 +0000

It’s great you post these refactorings, and they mostly make sense. Although I would really appreciate you answering the above asked questions, because this way it makes things more confusing.

By: Brad

Brad — Sun, 16 Aug 2009 23:35:00 +0000

And why does CalculateBalance accept a customer object?

By: Brad

Brad — Sun, 16 Aug 2009 23:28:59 +0000

Why is RentVideo in Video and accepting a video object?

Wouldn’t it be better to either move RentVideo to the customer object and only accept a video object OR rename it to RentToCustomer (or something along those lines) and only accept a customer object? With the first option being the preference, as video shouldn’t have to deal with the customer objects internal collection.

By: Claus Jørgensen

Claus Jørgensen — Sun, 16 Aug 2009 10:04:11 +0000

Since the Video.RentVideo method isn’t static, why would you need to pass the video argument along, opposite to doing it like this:

public void RentVideo(Customer customer) { customer.Videos.Add(this); }