观察者模式是否违反单一责任原则？

Question

If an application utilising the Observer design pattern has a subject class with the following responsibilities:

1) Managing and notifying observers (ie providing register and unregister functions and calling all observers notify functions) and

2) Its original responsibility (ie what ever the class was doing before it was a subject ).

Does this class violate the Single Responsibility Principle? It clearly has more than one responsibility but reading up on the SRP I am confused wrt 'reason for change' is this change at design time or run time?

Answer 1

Yes it does. But....

Let's go back a little bit to the the big idea behind design patterns, which is basically helping the developer dealing with future pending changes more easily.

The level of granularity set for your design is up to you, the path to the golden middle should be guided by your common sense, experience and the scale of the application.

If changes to the distribution of your repository are seen ahead you could create a midiator (pub-sub) that will be responsible to distribute your changes to the observers.

Answer 2

Answering my own question because although bav's answer links to a great resource it doesn't answer the question. (Although watching the video give me the understanding which allows me to answer the question!)

No, this is a misunderstanding of the Single Responsibility Principle (SRP).

The responsibility in SRP refers to a customer role who may initiate a change request. For example if a class Employee has the calculatePay() and displayEmployee() methods it could reasonably be assumed to violate SRP as calculatePay would 'belong' to the company accountant where as displayEmployee would belong to the reports clerk. This would mean two people with separate roles could request changes to a class.

The observer pattern does not add a new responsibility (as least not an SRP responsibility) as no customer role would care that this class publishes changes to its observers.

Answer 3

No, the Observer design pattern does not violate the Single Responsibility Principle (SRP) .

What is a responsibility?

"A responsibility denotes the obligation of an object to provide a certain behavior."
[Object-Oriented Analysis and Design, Grady Booch [et al.], page 600]

But the SRP defines a responsibility differently, as a reason to change. The SRP states that a class should have only one responsibility (reason to change).

This corresponds to the GoF principle of encapsulating things that change - a theme of many GoF design patterns. For example, the Strategy pattern encapsulates an algorithm (that can change) in a separate Strategy class.

The Observer pattern isn't about encapsulating things that change. It describes a way to define a one-to-many dependency between interacting objects without making the objects tightly coupled.

For further discussion see the GoF Design Patterns Memory for learning object-oriented design & programming at http://w3sdesign.com .

Answer 4

In my opinion: Yes the observer pattern does violate the SRP (sometimes).

Imagine the following class, part of a MVC application (Java pseudo syntax):

class Model {
    void setDateOfBirth(Date);
    Date getDateOfBirth();
    int getAge(); // calculated from date of birth
    void registerObserver(Observer);
    void unregisterObserver(Observer);
    void notifyObservers();
}

The first three methods are clearly related to managing the applications data while the last three methods are not.

The SRP states, a class should have only one reason to change[1]. I can think of multiple reasons to change the observer methods where the management of the applications data should not be affected. Some examples:

• I'd like to notify all observers in parallel for performance reasons.
• I'd like to notify an observer via some message bus because a new view runs in some other process.
• I'd like to register and unregister observers in parallel and thus need some other list implementation (one that is thread safe).

(One could argue, all this things can be hidden in an Observer itself. But registering an observer that allows to concurrently register other observers does not seem right either, IMO.)

BTW, the observer pattern also violates the DRY (don't repeat yourself) principle , because you need to implement the registering, unregistering and notification mechanism (ie the loop over all observers) over and over again.

But:

Should these two responsibilities be separated? That depends upon how the application is changing. […] If […] the application is not changing in ways that cause the two responsibilities to change at different times, then there is no need to separate them. Indeed, separating them would smell of Needless Complexity . — [1]

So you have to decide for yourself and balance SRP and DRY with needless complexity.

---

[1] The Principles of OOD by Robert C. Martin (aka Uncle Bob) and his book "Agile Software Development, Principles, Patterns, and Practices", chapter 8.