[Networkit] Interface conventions for analytics algorithms
christian.staudt at kit.edu
Wed Oct 29 21:14:52 CET 2014
Hi NetworKit developers,
by popular demand we are going to introduce some design conventions for the interface of algorithm classes. A unified approach will make the toolkit more intuitive for users. In the following I want to propose one.
Say you want to implement a new analytics algorithm. Here’s a sketch of how your class should look like.
Algorithm(Graph G, int a, double b, …. )
- Each algorithm is represented by a class.
- All input values and algorithm parameters are passed to the constructor of the class.
- A parameter-free run method triggers the computation when it is called.
- The result(s) of the computation are accessible through getter methods.
- This pattern decouples initialization and execution, which is often useful. For example, an algorithm object can be initialized anywhere and passed to code that calls it.
- Many algorithms calculate various values during the same computation. The getter methods avoid complex, nested return types. After the computation is done, the result is stored in the object instance, which can be asked for specific results.
- It’s at least three lines of code for any result. However, we can add one-line convenience functions on the Python layer for frequently needed results.
- The object has state. The getters must throw exceptions when the result is not ready, rather than crash. One more thing to keep in mind as a developer.
This pattern currently not consistent throughout NetworKit. Especially classes from the early experimentation days do not follow this convention and should be refactored at some point. But I used it for all recent classes of mine.
What do you think about this approach? Can you think of examples where this does not work?
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 495 bytes
Desc: Message signed with OpenPGP using GPGMail
More information about the NetworKit