The Single Responsibility Principle states that a class should do one and only one thing.  Some cases are pretty clear cut.  Others, though, are difficult because what looks like one thing when viewed at a given level of abstraction may be multiple things when viewed at a lower level.  I also fear that if the Single Responsibility Principle is honored at the lower levels, excessively decoupled, verbose ravioli code, where more lines are spent creating tiny classes for everything and plumbing information around than actually solving the problem at hand, can result.How would you describe what one thing means?  What are some concrete signs that a class really does more than one thing?  
Clarify the Single Responsibility Principle
design;object oriented
I really like the way Robert C. Martin (Uncle Bob) restates the Single Responsibility Principle (linked to PDF):There should never be more than one reason for a class to changeIt's subtly different from the traditional should do only one thing definition, and I like this because it forces you to change the way you think about your class. Instead of thinking about is this doing one thing?, you instead think about what can change and how those changes affect your class. So for example, if the database changes does your class need to change? What about if the output device changes (for example a screen, or a mobile device, or a printer)? If your class needs to change because of changes from many other directions, then that's a sign that your class has too many responsibilities.In the linked article, Uncle Bob concludes:The SRP is one of the simplest of the principles, and one of the hardest to get right. Conjoining responsibilities is something that we do naturally. Finding and separating those  responsibilities from one another is much of what software design is really about.