Schema definition

Let's take a look at the definition of observer mode in Dahua design mode: it is also called publish subscribe mode, which defines a one to many dependency, allowing multiple observer objects to listen to a topic object at the same time. When the status of the topic object changes, it will notify all observer objects, Yes, they can automatically update their status.

Its composition is roughly divided into at least four parts: observer interface, publisher interface, generally one publisher and more than one observer

Mode characteristics

Dividing a system into a series of cooperative classes, while maintaining the consistency between classes, observer pattern can avoid all kinds of close coupling.
When the change of one object needs to change other objects at the same time, and it may not know how many objects need to be changed, the observer mode should be considered.
The purpose is to decouple the coupling, so that both sides of the coupling rely on abstraction rather than concrete, so as to ensure that their changes will not affect the other side, and will notify the other party only when a specific state is updated.

Pattern implementation

C + + implementation case:
1. The first is the case mentioned in the simple big talk design mode: office employees A, B and C are watching stocks and movies. At this time, the boss comes back. The front desk after being bribed by A, B and C sends A notice to A, B and C. After receiving the notice, A, B and C quickly turn off the computer, close the stock window and pretend to be working.
The first is the observer interface, which needs to define updated virtual functions to be inherited by specific observers

class IObserver
{
public:
	virtual ~IObserver() {};
	virtual void updata(string strEvent) = 0;
};

The second is the publisher interface, which needs to define virtual functions, including adding observers, deleting observers and updating status information

class ISubject
{
public:
	virtual void addObserver(IObserver *ob) = 0;
	virtual void delObserver(IObserver *ob) = 0;
	virtual int notify(string strEvent) = 0;
};

Then the specific publisher rewrites the virtual function in the interface

class CBoss: public ISubject
{
public:
	virtual void addObserver(IObserver *ob)
	{
		m_listObserver.push_back(ob);
	}
	virtual void delObserver(IObserver *ob)
	{
		m_listObserver.remove(ob);
	}
	virtual int notify(string strEvent)
	{
		if (!m_listObserver.empty())
		{
			list<IObserver*>::iterator itObserver;
			for (itObserver = m_listObserver.begin(); itObserver != m_listObserver.end(); ++itObserver)
			{
				IObserver* pObserver = *itObserver;
				pObserver->updata(strEvent);
			}
		}
		return	m_listObserver.size();
	}

	void Come()
	{
		cout << "Boss : hello boys ,I come in" << endl;
		notify("Boss come");
	}
	void Leave()
	{
		cout << "Boss : Good bye boys" << endl;
		notify("Boss leave");
	}
private:
	list<IObserver*> m_listObserver;
};

Then write the specific observer and rewrite the update virtual function

class CObserver:public IObserver
{
public:
	CObserver(string NameObserver) : m_NameObserver(NameObserver) {};
	virtual void updata(string strEvent)
	{
		cout << m_NameObserver + " get " + strEvent + " call!!" << endl;
	}
private:
	string m_NameObserver;
};

Finally, for their use, multiple observer objects and specific publishers are defined. In actual use, they can be multiple objects of multiple specific observer classes. Then, the specific publisher adds the observer object to the observer list. When the specific state changes, the observer state will change.

int main()
{
	CObserver CObserver1("jams"), CObserver2("kobe");
	CBoss oCBoss;

	oCBoss.addObserver(&CObserver1);
	oCBoss.addObserver(&CObserver2);

	oCBoss.Come();

	oCBoss.delObserver(&CObserver2);
	oCBoss.Leave();

	system("pause");
	return 0;
}

Operation effect:

2. The second case is to quote the blog( https://blog.csdn.net/SuperYang_/article/details/79041345 )I think the example of the weather station in is also very good. Different from the above case, the addition and deletion of observers in the observer list in this case are written inside the specific Observer class. I think this will not be conducive to code expansion and maintenance. But the overall idea is worth learning from.

OK, this is the basic content of the observer mode. Later, we will start to update and record other design modes learned in the early stage. I hope we can return to the track of learning to brush questions later