single-responsibility-principle

Wikipedia describes the Single Responsibility Principle this way: The Single Responsibility Principle states that every object should have a single responsibility, and that responsibility should be entirely encapsulated by the class. All its services should be narrowly aligned with that responsibility. The traditional use of the controller in MVC seems to lead a programmer towards a violation of this principle. Take a simple guest book controller and view. The controller might have two methods/actions: 1) Index() and 2) Submit(). The Index() displays the form. The Submit() processes it. Do

I basically want to get an idea of the percentage of people who think it's reasonable to use the Single Responsibility Principle in real-world code and how many actually do. In Podcast #38 Joel talks about how useless this OOP principle is the real world; and further that this demonstrates how people like Uncle Bob have likely not written non-trivial systems. I've personally written or played a big role in a few software projects but have only now come across this pattern in my young career. I love the sound of this principle and would really like to start using it. I found Joel's argument in

In the SRP, a 'responsibility' is usually described as 'a reason to change', so that each class (or object?) should have only one reason someone should have to go in there and change it. But if you take this to the extreme fine-grain you could say that an object adding two numbers together is a responsibility and a possible reason to change. Therefore the object should contain no other logic, because it would produce another reason for change. I'm curious if there is anyone out there that has any strategies for 'scoping', the single-responsibility principle that's slightly less objective?

I have an algorithm to create a version for an entity and then I save that version against below 2 entity: 1) Variant 2) Category interface IEntityVersion { string GetVersion(); } public class EntityVersion : IEntityVersion { public string GetVersion() { return null; } } public interface IVariant { void Process(Variant model, string connectionString); } public abstract class BaseVariant : IVariant { private readonly IEntityVersion _entityVersion = new EntityVersion(); public void Process(Variant model, string connectionString) { try { Transform(); string variantVersion = _entityVersion

What is the difference between Single Responsibility Principle and Separation of Concerns? Single Responsibility Principle (SRP)- give each class just one reason to change; and “Reason to change” == “responsibility”. In example: Invoice class does not have a responsibility to print itself. Separation of Concerns (since 1974). Concern == feature of system. Taking care of each of the concerns: for each one concern, other concerns are irrelevant. Hiding implementation of behavior. From here . Matthew Groves Separation of Concern vs Single Responsibility Principle ( SoC vs SRP ) From the linked

I am struggling to understand how the Single Responsibility Principle can me made to work with OOP. If we are to follow the principle to a tee, then are we not left with many classes, many of which may just have one method each? If we don't follow the principle exactly, then what is the point in the principle? I like to state the single responsibility principle this way: "Every thing you write -- every module, class, interface, or method, should have one job. It should do the whole job and only that job. Notice that some of these things you write are big (modules), some are small (methods),