4

Firstly, I am an absolute beginner in programming, so don't make fun of me too much.
The only thing that I have seen signals used for are GUI toolkits, and GUI toolkits all come with their own signaling. So, can Boost:Signals even be used with these GUI toolkits? Would this be a good idea? What other applications do signals have?

Jay
  • 6,572
  • 3
  • 37
  • 65
Patrick
  • 1,894
  • 3
  • 15
  • 17

4 Answers4

6

Signals is an event messaging implementation, much like Smalltalk/Objective C Messages or Events in various other (e.g. C#) lanugages.

You can use them for a wide variety of tasks, take a look at the Observer Pattern

Why would you use the Observer Pattern?

The benefits are largely organisational, when you work with large applications it's is important to apply patterns of reuse that help maintain development team coherence.

When the implementation of a particular pattern becomes de facto (or close to) it's especially useful because it means that lead up times for new team members are likely to be expedited, not only if they have used the implementation before, but also because the popularity of the implementation will mean that there are widespread resources, and documentation available to speed learning.

From a pure code perspective, ALL patterns appear as bloat, but when you begin to understand that upwards of 60% of the costs involved in software development are in maintenance life-cycle, it is well worth the additional code to gain coherence.

The other benefit is to aid in software reuse, depending on the style of implementation, the Observer Pattern can assist in modularising and decoupling classes from one another. I would suggest that this is also an organisational benefit, in as much that different teams can build components more easily, or simply because components are easier to replace.

ocodo
  • 29,401
  • 18
  • 105
  • 117
  • The observer pattern just seems like extra code to call a method. It seems that I could just call the method of the object I want instead of creating a signal and having the object catch it and then start one of its methods. Maybe I am missing something? – Patrick Nov 25 '10 at 11:46
  • 2
    @Patrick, For the Observer Pattern, you're wondering why you would call notify(), pass it some message, and thus have notify() call foo() -- instead of just calling foo() directly. If you know which class you're dealing with, you probably could call foo() directly, but the idea is to decouple the modules. Your module doesn't need to know the details of the Foo module -- it just needs to notify() a Listener (and Foo happens to be a listener). By breaking this dependency, Unit Testing and Maintenance are easier. It's also easier to notify a Bar object (or any other listener) in the future. – Tim Nov 25 '10 at 23:00
  • 1
    Thank you both. I am just starting to learn that everything should be separated and it makes a lot of sense. Thank you for such an in depth explanation. – Patrick Nov 27 '10 at 02:02
4

Just my two cents, signals are not only used in (or for) GUI toolkits. They are used in contexts where you want to decouple the producer of a datum with the receiver of it (the observer pattern mentioned above, for example). If you mix that idea with threads, you can implement actors easily, an interesting pattern for concurrent tasks (Erlang and Scala use actors, for instance).

Diego Sevilla
  • 28,636
  • 4
  • 59
  • 87
  • 1
    will be callback in this case be executed on behalf of data producer thread/actor? What if I want the data be processed by receiver on behalf it's own thread? Do I need for this some sort of thread-safe queues? – dimba Nov 26 '10 at 09:24
2

One possible use would be in the implementation of a GUI toolkit. You'd basically set up the wiring to get messages (or whatever they happen to be called) from the native system to produce signals. From there, the code for routing and handling signals can be (at least somewhat) portable.

Jerry Coffin
  • 476,176
  • 80
  • 629
  • 1,111
2

In addition to the Observer pattern that others have mentioned, anytime you find yourself having to write a callback function, so that one class can notify another that something has happened, then you can use Signals and Slots instead. The great advantage over callbacks is that it takes care of lots of the boiler plate code to add and remove the callback function, and deals with automatically disconnecting when either the caller or the callee go out of scope.

Callbacks are really just an instance of the Observer pattern though.

the_mandrill
  • 29,792
  • 6
  • 64
  • 93