The .NET Buffet - All Comments

Twitter Trackbacks for The Dangers of Hammers (or, Why SRP Isn???t Dangerous) - The .NET Buffet [asp.net] on Topsy.com

Sat, 21 Nov 2009 03:35:49 GMT

Pingback from Twitter Trackbacks for The Dangers of Hammers (or, Why SRP Isn???t Dangerous) - The .NET Buffet [asp.net] on Topsy.com

re: In response to "The Dangers of Single Responsibility in Programming"

Jonathan Allen — Fri, 20 Nov 2009 20:39:41 GMT

When I see things like ICustomer, I can't help but think you messed up. The chances that you need to expand on the Customer class is high. This means breaking the ICustomer interface, which is bad, or creating ICustomer2, ICustomer3, etc, which is worse.

re: In response to "The Dangers of Single Responsibility in Programming"

David Cooksey — Thu, 19 Nov 2009 17:01:58 GMT

Doug,

You make a number of good points, but given the number of arguments I've been in regarding the SRP, I feel that 'got it wrong' is insufficiently descriptive. I don't believe that we are in disagreement about SRP's application, but I do feel that the frequency with which the SRP is misunderstood is a good indication of how dangerous it is. I have a more detailed response posted.

The Danger of Single Responsibility in Programming Continued | Thycotic Software Ltd. | Team Blog

Thu, 19 Nov 2009 14:48:13 GMT

Pingback from The Danger of Single Responsibility in Programming Continued | Thycotic Software Ltd. | Team Blog

re: In response to "The Dangers of Single Responsibility in Programming"

Dhananjay Goyani — Thu, 12 Nov 2009 11:21:31 GMT

Nice explanation...

re: In response to "The Dangers of Single Responsibility in Programming"

drohrer — Thu, 12 Nov 2009 02:08:01 GMT

Phil - Actually, if you look at the initial problem David put together, there are several types of pricing rules that can apply. Some of them override prices, and some of them modify the previous price. Therefore, the way I implemented it was to pass the "current" price in the loop to each calculator, and let them figure out how to update/modify the price. More specifically, the "Gold Member" price is calculated based on the base price, but if the item is on sale and the sales price is lower than the currently calculated price, the sales price is returned. In this way, you allow all pricing calculators a chance at processing the price. Perhaps there should be some sort of out param that would indicate that price calculations should stop after a certain calculator runs (allowing it to override all other calculator values) but that didn't seem to be part of the business requirements at the time. Does this help you understand it a bit better?

re: In response to "The Dangers of Single Responsibility in Programming"

Phil — Wed, 11 Nov 2009 23:03:21 GMT

I am a little unsure of this function:

public decimal GetPrice(IProduct product, ICustomer customer)

{

decimal price = product.BasePrice;

foreach (IPriceCalculator calculator in _calculators)

{

//Right here needs to find the correct //calculator, right?

price = calculator.CalculatePrice(price, customer, product);

}

return price;

}

I think you want to use your IoC container to get the correct calculator. This code will just overwrite price and return whatever the last calculator added calculates. A bit confusing for those unfamiliar with DI.

Thanks

re: In response to "The Dangers of Single Responsibility in Programming"

drohrer — Wed, 11 Nov 2009 14:26:50 GMT

sifarrell: Yea - as I said in the original post, I would probably use some DI/IOC container (StructureMap is my personal favoriate right now) to load the calculators - which would handle the open/closed principle issue, but lacking some sort of DI container I would do something like you suggest and pass in the calculators as a constructor parameter.

Dew Drop – November 11, 2009 | Alvin Ashcraft's Morning Dew

Dew Drop – November 11, 2009 | Alvin Ashcraft's Morning Dew — Wed, 11 Nov 2009 13:56:21 GMT

Pingback from Dew Drop – November 11, 2009 | Alvin Ashcraft's Morning Dew

re: In response to "The Dangers of Single Responsibility in Programming"

sifarrell — Wed, 11 Nov 2009 07:36:53 GMT

Great post!! I've been trying to get my head around real work implementations of the SOLID principles.

To make the code adhere to the open closed principle you could extend the Pricer class to take in a list of calculators, therefore none of your core code classes would have to change.

private readonly List<IPriceCalculator> _calculators;

public Pricer(List<IPriceCalculator> calculators)

{

_calculators = calculators;

}

Thanks