+ 3
Reverse observer pattern : remove dynamic_cast
Hi I have an alarm and it is blown where either of three boiler's temperature raises above 100 degree. I tried to do this using reverse observer design pattern (Many to one relationship). Two queries as below: 1. Is this design okay for this scenario? If not, what is best way to do this implementation? 2. Alarm::update does dynamic cast and could not find a way to get rid off this. How to do so ? https://sololearn.com/compiler-playground/cF2Asqz02IPM/?ref=app
16 ответов
+ 4
No, a standard Observer Pattern is simpler. Instead of making Boiler an observer, let Alarm observe Boiler directly.
Alternatively, a callback function can be used for a more lightweight approach.
How to remove dynamic_cast?
Use a specific interface (IBoilerObserver) instead of a generic iObserver.
This way, Alarm implements IBoilerObserver, and Boiler calls onTemperatureRise() directly without type casting.
+ 2
In your case, it's still an observer pattern, but in reverse:
Boilers are subjects that notify a single Alarm (observer) when their temperature exceeds 100°C.
The Alarm listens to changes in state from all boilers.
This is a many-to-one relationship, where multiple subjects (boilers) notify one observer (alarm).
I dont know If this will Help you
+ 1
I don't think you can avoid the cast.
The base class is not aware of the additional methods of the child class.
+ 1
no, that's just how inheritance works
Design patterns and inheritance introduces extra complications.
you know you can just write one class. It would be more self-contained and would not tangle everything into a complicated mess
Take the simpler approach to get the task done. In the end, everything gets optimized by the compiler anyway. Your complex patterns might end up harder to optimize or slower to compile.
https://sololearn.com/compiler-playground/c3fwg2cGZlRT/?ref=app
+ 1
ok. so we are to assume your example code is just a representation of the real code you are working on and you are trying to implement new features on it?
Is this a school assignment or professional work ?
your topics are interesting because they're complicated approaches to otherwise simple problems.
the conditions and requirements on the other hand seems artificially restrictive. It feels more like trying to hack an existing codebase.
+ 1
Idk, structuring C++ like Java seems counterproductive. As with most things, just because you can doesn't mean you should ...
+ 1
it is good to know, but trying to apply it to everything is going to slow you down.
imagine you have a simple problem, would it be wise to use the most complex solution? of course not.
but knowing design patterns and how to use them could be useful if you have a project that you know would need to expand and grow in the future. Then you can add functionalities to your code as the need arises, theoretically.
But then again, it's rare and the entire codebase gets refactored anyway because of totally new requirements...
0
I am getting confused there only D1M3
How standard observer pattern works here ? Its not a one to many. It is many boilers state change to be observered by a single alarm.
One alarm observer has to observe the three boilers
0
Tbh i dont quite Understand either. Im trying my best to remember anything related
0
Here is the code with boiler as subject + alarm as observer and it also requires dynamic cast:
https://sololearn.com/compiler-playground/caLK9O39R3Ez/?ref=app
0
Salut
0
That means existing desing is not food and need to be modified if I am not wrong
0
Bob_Li plz understand that design pattern don't make code complicated.
Your code is changing the requirement. Boiler has no implementation to signal alarm. It is different object which blows alarm and code is loosely coupled. Everything cannot go into same class
0
It's neither. I am trying to learn software design.
0
First one I know now who says design patterns are counter productive
0
Ascav