The .NET Buffet - All Comments

re: Enterprise Library Configuration (Part 2/2): Customizable configuration with framework extensions.

gelu53005 — Tue, 09 Nov 2010 20:05:57 GMT

can you provide the source code; your link doesn't work.

thanks

re: Enterprise Library Configuration (Part 2/2): Customizable configuration with framework extensions.

gelu53005 — Tue, 09 Nov 2010 20:02:51 GMT

From what DLL or reference do you get ConfigurationProvider class?

The Danger of Single Responsibility in Programming Continued « Thycoticsolutionsblog's Blog

Mon, 21 Jun 2010 18:07:25 GMT

Pingback from The Danger of Single Responsibility in Programming Continued « Thycoticsolutionsblog's Blog

re: Silverlight ChartHelper revisited...

seaman — Mon, 15 Mar 2010 14:57:11 GMT

it's very great !!!

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

Pieter — Wed, 03 Feb 2010 04:44:31 GMT

Started working on a system where SRP was applied almost vigorously, and everything is tested. Only problem is in readability. The source code for a 2 form application and 5 functions has more than 50 source code files, and supporting code to make everything stick together. It is next to impossible to read and almost impossible to stick anything together mentally. Even the original creator took 5 hours to implement a "close" button.

It is difficult to get the balance right, so you don't over create a big application.

I agree with this post though, wondered how to change that function and how to test it, and it makes sense, but it also makes sense for it to be all in one source code file, then you can actually read and follow it.

re: The Dangers of Hammers (or, Why SRP Isn’t Dangerous)

David Cooksey — Tue, 01 Dec 2009 15:31:45 GMT

Doug,

At this point I believe we agree in principle on what single responsibility is and how it should be applied. It appears that our disagreement is primarily based on whether 'danger' is applicable to the SRP or not.

I'm not trying to scare people away from SRP, my primary intention is to slightly curb the enthusiasm of the developer who is new to the SRP and may have a tendency to apply it as a law. Also, I want to steer people away from the 'one class, one method' concept based on the SRP.

Or, to extend the hammer analogy - be sure that you know where the nail should go before you start hitting nails with your shiny new hammer. The amazing hammer tool won't keep the house together unless its applied with understanding ;)

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