Matteo Vaccari

Matteo Vaccari

It is possible to write software that solves real business problems, cheaply and reliably. The recipe is well known, even though it's not easy to do.

I am a software developer. I'm happy to work as a programmer for ThoughtWorks, mostly in the Milano area. I used to teach at the Università dell'Insubria.

On 19 Jun 2012, at 07:08, Nikolay Sturm <...> wrote:
> Hi,
> I am rereading GOOS in our company's book club atm and one question
> neither of us could make sense of was the relationship between the
> Single Responsibility Principle and the notion of objects as
> implementations of one or many roles, with each having one or many
> responsibilities.
> At 1st, 2nd and 3rd thought, these ideas seem to be opposed to each
> other. How do I get them into a coherent picture? Thoughts anyone?
> cheers,
> Nikolay

The word "responsibility" is being slightly differently in the two uses. SRP is about responsibilities in the system. We were talking about the responsibilities of correctly playing a role in a protocol between objects.

For example, suppose we have a system that communicates over a network but must not send messages faster than some maximum rate. Our system needs to rate limit the sending of messages. We would want to implement the rate limiting responsibility in one class -- not have it intermingled with formatting the contents of messages or transmitting them over the wire -- and compose it into the system. But a class that performs rate limiting must collaborate with other objects: play roles in protocols between objects. It must be able to send and receive messages via some lower layer transport and request and receive timer callbacks. To play those roles correctly it must follow certain rules -- that is, it has a responsibility to send correct requests & responses to its peers and respond appropriately to correct requests & responses it receives from them. For example, it might not be allowed send a zero length message or send a message to a wildcard address, and it must announce a "stop sending" notification if the rate limit has been reached and a "start sending" notification when peers can send messages again.

Nat Pryce on the Growing Object-Oriented Software mailing list