The Danger of Single Responsibility in Programming Continued
Doug Rohrer responded to my initial post on this topic with a good refactoring of the classes involved in a manner similar to the Strategy pattern. I agree with many of his points—the hypothetical developer certainly chose the wrong responsibilities; misunderstood the Single Responsibility Principle; and generally made the code a mess. That said, I believe that SRP is most definitely dangerous, not because of what happens when it is used correctly, but because of how easy it is to get it wrong. Misapplying the SRP can result in code that makes God objects look easy to maintain.
The Dangers of Single Responsibility in Programming
Let’s take a look at a possible system built for a company that sells a wide variety of products. This system was originally built around a Product object, and over the years the product object has continued to grow and acquire responsibility as new features were added to the system. The IProduct interface now looks like this:
The Design and Development Benefits of CSS
A common problem in many businesses is that everyone works on a separate aspect of a project and then brings it together and tries to make it look uniform. Inline styles, BRs, and HTML tags can make a page look the way you want it to, but when you want to change the look of your site, you’ll find these methods can be a real pain. The problem will be even greater for your designer. Each page will be a single design, too complex to change easily and cost-effectively.
The Facade Pattern – Don’t Talk to Strangers
The engine ignition switch is our facade class. It hides the ugly workings of the engine from us and we simply say “Make Go” and it works.
The Adapter Pattern, A Code Diplomat
Then your boss walks into your office and tells you that the higher-ups have purchased a commercial package that wraps the EasyBank API, and they want you to use it.
Uh oh.
My two and a half cents – pitfalls with rounding
Bryant and I came a across an interesting issue when comparing two values that appeared identical, but which the code insisted were different. Our research lead us into the internals of ASP.Net rounding to solve an infrequent but legitimate concern.
A Developer’s Uphill Journey From Custom Development to Software Vendor – Part 2
Our approach was to focus on the pain that our product solves.By delivering the core pain-relieving features, we would have a product that was genuinely useful and could then be refined and tuned based on customer feedback. This strategy put our product in our customers’ hands quickly, solved a few of their main problems, and began generating a stream of feedback to then drive requirements for the next phase
A Developer’s Uphill Journey From Custom Development to Software Vendor
This is the typical world of the corporate developer-ugly applications with aggressive time lines, and very forgiving users. How well do these traits relate to the world of the software vendor marketing to the public at large?
