참조: 
http://www.objectmentor.com/resources/articles/srp.pdf
헤드 퍼스트 OOAD (영문판) 390p
http://www.zdnet.co.kr/ArticleView.asp?artice_id=00000039135552
실용주의 디자인 패턴 (Holub on Patterns) 6p

Single Responsibility Principal, 보통 단일 책임 원칙이라고 하는데 여기서 "책임"이란 "변경 이유"에 해당한다. 따라서 이 원칙은 다음과 같이 재해석 할 수도 있다. 

어떤 클래스는 한 가지 이유로만 변경되어야 한다.
즉, 여러가지 이유로 해당 클래스가 변경된다면 그 클래스에 여러가지 책임 있다는 말이다. 또는 반대로 책임이 여러 크래스로 분산되어 있어도 문제다. 어떤 기능을 하나 손 보려면 여러 클래스를 두루 두루 손봐야 할지도 모르기 때문이다.
"한 가지 일"이라는게 클래스에게 지나친 제약이지는 않을까? 그렇치 않다. 스윙의 JTable은 백여개의 메서드를 가지고 있다. 하지만 그 모든게 테이블과 관련된 작업들이고 여러 리스너 인터페이스들을 구현하였기에 SRP를 잘 지키고 있는 예제로 볼 수 있다. 즉 지나치게 클래스를 제약하지 않는다.
응집도(cohesion)는 SRP의 또다른 이름이기도 하다. 높은 응집도를 가진 소프트웨어를 작성할수록 SRP를 잘 적용하고 있는 것이다.  
http://code.springsprout.org/browse/SpringSprout/src/springsprout/modules/member/MemberServiceImpl.java?r=HEAD
자 위에 있는 봄싹 코드에서 SRP를 위반한 코드를 찾아서 해당 코드를 작성한 사람에게 따지도록 하자.