Voting mode
1. Context: This design pattern is abstract from multi-person voting model, where participants VOTER is a voter, and each voter maintains a state count, and vote () can change the state of count, Counter is a bill, each voter can contact Counter through attach () and detach () operation, while the Counter notifies each registered voter to vote, then vote vote via the countwinner () to statistics, others The user gets the final voting result over the getCount () operation. All of these count members variables are in the same range. It is very similar to the observer mode, and the difference is that the observer mode emphasizes the status consistency of both the maintenance, and the Voting mode emphasizes parallel processing and statistics for processing results.
2. Mandatory: The same thing is handled by multiple different handlers (the same interface, different implementations), and then summarize the results.
3. Effects: Abstract Coupling of PVUNTER and VOTER
Every counter is known to have a series of VOTERs, each in line with abstract voter simple interface. Counter does not know which specific class belongs to any VOTER, the coupling between the two is the smallest.
2. Support broadcast communication
Note: This mode is what I thought 2 years ago. Later, I saw that this is actually a variant of the "main control-dependent" mode.
