#Srp single responsibility principle code#

#Srp single responsibility principle code#

It was necessary to apply a certain transformation to all of these code blocks (for those interested: I needed to replace the conceptual user variables with actual implementation variables in order to prevent variable clashes. Furthermore, it is possible to annotate Actions and Iterations with codeblocks, which define the actions and conditions to evaluate as the coroutine walks ahead. Sequence chains two coroutines, Iteration repeats a coroutine until a userdefined condition is true and Action performs a certain userdefined action. For now, think of the nodes as Sequence, Iteration and Action. I had a cetain abstract syntax tree of a coroutine which will be generated into C later. I recently had this in the following way: If you feel the need to either write some sort of cartesian product of cases in your test cases, or if you want to mock certain private methods of the class, Single Responsibility is violated. I think this is at the heart of OOD and the SOLID principles, including SRP.Īnother rule of thumb I'd like to throw in is the following: Thinking about these things results in programs that are easier to understand, maintain and extend. I guess you should ask yourself: What problem is your class trying to solve? Has the important information you need to solve this problem risen to the surface? Are the unimportant details tucked away so that you only have to think about them when absolutely necessary? At the same time we can use encapsulation to hide the 'unimportant' details so that we only have to deal with them when absolutely necessary. Modeling forces us to focus on the important details. The main purpose of modeling is to present a problem in a way that allows us to understand it and solve it. The big question for me is: What problems is SOLID trying to address? I've also been trying to get my head around the SOLID principles of OOD, specifically the single responsibility principle, aka SRP (as a side note the podcast with Jeff Atwood, Joel Spolsky and 'Uncle Bob' is worth a listen). I'd rather err on the side of 'too little' than 'too much' myself. By the time you finally get around to it, the different responsibilities of the class will have become entwined in the client code making it hard to factor one thing out without breaking the other thing. I also find that refactoring to single responsibility is hard. Doing nothing is the limit of that, and yes, I have seen that in practice, with an 'empty' parent class definition just to group together a bunch of unrelated classes in a single hierarchy. It's usually a sign that the parent class does either too much or too little. If you end up with an excessively 'deep' hierarchy (a long list of derived classes until you get to leaf classes) or 'broad' hierarchy (many, many classes derived shallowly from a single parent class).If you find you need several 'friend' classes or functions, that's usually a good smell of bad SRP - because the required functionality is not actually exposed publically by your class.

Perhaps a little more technical than other smells:

Finding that you are making changes to the same class for unrelated bug-fixes again and again is another indication that the class is doing too much.

making a change to one area in a class causes bugs in unrelated areas of the same class.

Another code smell from the refactoring book would be HUGE classes.

If you're having trouble getting all the responsibilities of that object on a CRC card, it's probably doing too much. If you employ a CRC card, it's a nice subtle guideline.Why would you want a single object to do all these? ( it's okay if a class takes on multiple responsibilities as long as they are all related and coherent.) However you wouldn't ask the same person to do your manage files, compute salaries, issue paychecks, and verify financial records. If the object were a person, who would I ask to do this? Assign that responsibility to the corresponding class. a service that the object provides for its clients.Ī nice way to stay on the road. to avoid class explosion.Ī single responsibility does not translate to single method classes. Well, this principle is to be used with some salt.