Twisted Sevices

Twisted is one of the more mature Python networking libraries in existence. It has been around for over half a decade and has a very feature-rich code-base. There are several sever types that can be implemented with Twisted. This is actually a real requirement for many applications. For instance, an web application will obviously need an HTTP server for the web front-end. That same application may also want to provide a lower-level server for an API that generates less overhead. However, having to write something custom just to ensure that these servers are started along with the application seems a bit much. Especially if the servers are both a Twisted implementation. Luckily, Twisted has just the solution for this scenario.

Twisted provides developers with a MultiService class that is used to create multiple network service that behave logically as one server. Server implementations in Twisted can set the parent service to be an instance of MultiService. This MultiService instance can then be started with multiple child servers.

However, one last step should be taken. In order to make your service work with the twistd command, that is make it a sub-command, you must make the service properly. This is done by implementing a class that implements the IServiceMaker interface. This same class should also implement the IPlugin interface since it is a Twisted plugin in addition to a service.

The IServiceMaker interface requires attributes that dictate the name of the sub-command used with twistd. Also, command parameters and a description are part of the interface and should be provided.

This is a really nice way for an application to manage multiple services provided by the same application. It also goes to show that Twisted's experience is also reflected in the API.

Instance Factory

A factory in object-oriented programming is a design pattern that creates instances of classes. There are variations on this pattern but for my purposes, I simply refer to it as an instance factory because that is essentially what it is used for. The factory takes the responsibility of directly instantiating a class from the context that uses the factory. That context may be some function or, more often, some method of another class. The factory itself is generally a class with several static or class methods. It is these methods that construct and return instances.

So if the developer can take the responsibility of directly instantiating some class away from the method they are currently working on, what do they gain? In this case, it isn't what they gain but what they lose. They lose the direct coupling to the class in question. In most cases, a given class is going to need to create more than one type of instance throughout its' lifetime. This means that there is a dependency between the class in question, serving as the context, and the other classes that it depends on. If the class in question requires only a factory, the class then becomes loosely-coupled. This is an important design factor.

The instance factory is essentially a proxy for the act of creation. It isn't a proxy for data but for behavior. This is the sole responsibility of the factory. If a developer can see a factory invocation in code, chances are that their guess as to what it does will be correct. Since the instance factory is so specialized, it will in turn help with the distribution of responsibilities where ever it is used.

Gaphor element factory

The Gaphor UML modeling tool, written in Python, defines a UML element factory. The factory, given an instance of the Gaphor Application class, can construct UML element instances as Python objects. These Gaphor components may be used from within Gaphor plugins or independently of Gaphor entirely.

Consider the following example.

#Example; Gaphor factory.

from gaphor.application import Application
from gaphor.UML.elementfactory import ElementFactory
from gaphor.UML.uml2 import Class

if __name__=="__main__":
  factory_obj=ElementFactory()
  factory_obj.init(Application)
  class_obj=factory_obj.create(Class)
  class_obj.name="MyClass"
  print class_obj.name
  print class_obj.id
  class_obj.unlink()
  factory_obj.shutdown() 

Here, we construct an element factory and pass it the Gaphor Application instance. Next, we create a Class UML element. Finally, we set an attribute of the element, destroy the element, and shutdown the factory.

We can construct any UML element from the Gaphor uml2 module which is automatically generated. Very neat stuff.