Yep. Naming things is hard.

There are only two hard problems in computer science: cache invalidation and naming things.

Phil Karlton¹

So I've been reaing Uncle Bob's Clean Architecture as part of my continuing education. I'm in the bit where he's talking about SOLID in gneral and trying to explain the Single Responsibility Principle in particular. Uncle Bob admits that it isn't well named. Nice mea culpa. Still, it's not too bad a job. Especially if you compare it to the naming of the principle widely know as RAII.

Anyway, moving on to defining this thing Uncle Bob gives the original statement of the principle as:

A module should have one, and only one, reason to change.

Which he immediately admits isn't particularly clear, so he then suggests the intermeidate form:

A module should be responsible to one, and only one, user or stackholder.

This is also less than perfect as there will often be a group of related users or stackholder who hold the module's specification collectively. To remedy that Uncle Bob tries:

A module should be responsible to one, and only one, actor.

Which is more pithy. Alas he needed a separate sentence to nail down the meaning of "actor" in this context.

It seems to me that "faction" might be a better word here. Admittedly there is a contation of conflict or at least competition that comes with that choice. But, honestly, the different groups of stackholders who rely on a medium to large scale software project are in competition for programmer hours if nothing else and they often have to hash out conflicting interests in specifications as well.

---

¹ Yes, I'm a big fan of the variation that includes off-by-one errors in the list of two things. But the original is insightful enough that Phil deserves plenty of recognition and it is hard to find a authoritative origin for the expanded version.