+16  A: 

SRP does not apply to UIs. Keep in mind that even though the button is called "Save and Close" there can undoubtedly be two separate methods or types to handle the saving and closing functionality. The button simply ties those two separate pieces of functionality together.

If you feel the need to violate SRP then you need to re-evaluate your approach. Any SRP violation can be refactored into a new method or type that exposes the composite functionality by means of composition of the two pieces.

Andrew Hare  2009-04-02 14:08:28
Actually, it applies to the UI, also. But this example shows a UI thing that is implemented by some Control and/or Model things under the hood. The question conflates UI changes with Model/Control changes; which doesn't make much sense -- each was built following SRP.
S.Lott  2009-04-02 14:11:35
Yes, I agree with you. After re-reading my first sentence I realized that I am, in fact, incorrect. I think I will leave it there as your comment won't make much sense if I remove it. I appreciate your incisive comment and I don't want it to appear out of context. :)
Andrew Hare  2009-04-02 14:14:19
@Andrew: By your comment, you mean, SRP should never(yeah bad choice of word) be violated and if it were to be violated, code structure need to change instead?
Sung Meister  2009-04-02 14:20:35
I think "never" is just the right word. Often times the usage of "never" is very hyperbolic but in this case it isn't. *Any* violation of SRP can be refactored to remove the violation with minimal effort. I guess what I am trying to say is "Yes". :)
Andrew Hare  2009-04-02 14:28:04
@Marked as Answer: Thanks Andrew. your explanation was clear in both answer and comments.
Sung Meister  2009-04-02 14:31:14
+1: SRP is **never** violated -- that's precisely why a GUI is split into Model, View and Control.
S.Lott  2009-04-02 17:36:27
Sung Meister  2009-04-02 21:13:12

related questions

Should logging reside within a class who's primary purpose is not logging?
SRP applied to a workflow example: how to structure the classes in a sensible way
Uncle Bob style OOP in VB.NET: how to learn?
Difference between Single Responsibility Principle and Separation of Concerns
When an operation needs to pass more than just the result, do you tuple/throw/or getContextual?
What is a good way to show the relationship between loosely coupled classes and interfaces?
Is this a violation of the single responsiblity principle?
What is your best example of a violation of the Single Responsibility Principle?
Confused about Single Responsibility Principle in the following example
Single Responsibility Principle: do all public methods in a class have to use all class dependencies?
Single Responsibility Principle: Should I separate my bibliography class in Reader, Writer and Container class?
ASP.NET MVC: Authorization inside an Action - Suggested Patterns or this is a smell?
What does the single responsibility principle mean for validation
Typecast or convert method?
Static factory on business object a violation of Single Responsibility Principle?
Determining Class Responsibility and Collaborators
Making a class follow OCP - Factoring functions into objects
Using the Single Responsibility Principle in the "real world"
Implementation question on Single Responsibility Principle
How to use the single responsibility principle in large wcf services?
How to go from bad to good OOP design?
How do you define a Single Responsibility?
Aren't Information Expert / Tell Don't Ask at odds with Single Responsibility Principle?
Who's responsibility is it, anyway? A design question.