My Interpretation of the Signals and Slots Pattern


What happens

An ObservableClass ‘emitssignals when something interesting happens.

Examples of interesting things:

a property change in a bean;

a new db connection up;

a window closes

Emitting a signal is something that has to be done manually by the programmer after they’ve done the interested thing


setProperty(Object newValue) { = newValue;



It means tell all the InterestedClasses to check out the signal and optional newValues passed and do something with it in a slot method

To let the ObservableClass know which InterestedClass methods to call (slots) when we emit the signal, we must connect them to each other.

We could also connect multiple slots to signals

Once connected however, the connection is quite loose.

The slot method is usually referred to as a string (though we could use closures in future). Thus slot or slots to execute when a signal is emitted is determined at runtime, by looking at the parameters in the emit and matching them to the parameters of the connected slots (methods).

Implementation Use Case:

  1. We are interested in one or more discrete events that happens in the lifetime of the Observable Class.
  2. We create Signal objects to represent each of these events that could ever be emitted by the ObservableClass. We usually do this in the constructor of the ObservableClass
  3. We update our methods to emit signals (call the emit method straight after the interesting thing has occured)
  4. If we want to send some event context data to any interested listeners (slots), we can pass parameters to the emit to pass on when the Signal is fired.
  5. In another class (or maybe even same one?) we write a method to execute when the interesting thing happens. This is called a slot
  6. We connect the signal to the slot via a connect method
  7. When the interesting thing happens, the emit method on the Signal object is called. emit is responsible for letting all the connected slot methods to know to fire.

    Other Notes (extentions)

  • A signal can be connected to multiple slots (methods) in any number of different classes
  • You can chain signals together
  • Communication is one way from the Signal event to the InterestedClass.
  • The params in emited in the Signal can be more than the slot method (but not the other way around)

Comparison to the usual way done in Java Swing (Observer Pattern)

In Java, an Observable Event occurs. InterestedClasses must register their interest with the observable class.

The ObservableClass must keep track of who is listening and notify each of them when the event occurs.

The InterestedClasses must all implement the same notification method (and full method signature) in order to use the event. Potentially less runtime mistakes because the IDE will pick up at compile time

Remember the Signals and Slots pattern doesn’t care about the method signatures of who is listening and effectively can fire updates to different methods of different types.

So you want to be a ClassLoader champion?

It wasn’t until earlier this year when I started learning Scala that I had to venture into how a class was loaded in Java.  It wasn’t that Scala required you to know it, it was simply that they made reference to the Java class path loading basics. I think it was to demonstrate that if you wanted to use Java class, where it would be pulled from and when.

 Previously, at best the only thing I’d had to worry about the order that classes were instantiated and by whom, mainly when sorting out issues of Hibernate either having Lazy cglib instantiations when they were meant to be real classes and vice versa.  A completely different problem but the only time I’ve had to worry about the way objects and classes come to being.

Yesterday while flipping through Head First Design Patterns, I also came across the discussion about Class Loaders when talking about Singletons and having two threads instantiate a Singleton class each and how to avert the problem.

 Today, one of the senior developers was summarising an issue we had at work and mentioned that our custom ClassLoaders used by our webstartable app may have been the cause of the problem.

The universe is asking me to learn about classloaders, hehe….

 So, in short, there are three class loaders in the JVM.

  1. Bootstrap class loader – loads all the classes/jars in the JAVA_HOME/lib directory
  2. Extensions class loader – loads classes/jars in the JAVA_HOME/lib/ext/   (Something reminds me here of the libraries Quicktime would install, and if not, those hooks that Mercury Quicktest Pro would use to get into your java app to automate it)
  3. System class loader – looks at your CLASSPATH variable

So you can make your own classloaders in addition to these.  Wikipedia’s article sights reasons of encryption, rmi, basically any time you need some dynamic class loading :).

 A google search was rich with resources:

JBoss wiki contains a tutorial on ClassLoading

The basics of Java class loaders

OnJava’s article: Internals of Class Loading