AdaptiveTraversals
Last updated: 11/17/2004

AdaptiveTraversals is a port of the DJ Library to the .NET Framework. The intent of the project is to make the DJ library (part of the Demeter project) available to.NET programmers no matter the language they choose.
This means that the structure-shy programming style of Demeter can be used by developers using languages such as C#, C++, J#, VB, Eiffel, Perl, Python, etc.

Project Information

APRlib API ( under construction )

dCsharp API ( under construction )
 

Project Progress

In this section I pretend to keep updates of the steps that I am making in the porting so I can get some feedback and suggestions. I am going to put also links to information that I consider useful.

Phase 5 (Current)

I already got the software working for simple cases so in this phase I am focusing in improving the use of Reflection and also completing the Strategy factory to generate more complex strategies.
These are some of the changes going on:

  • In DJ and APLib the tracking of the classes and fields/methods already added to the ClassGraph were maintained by classes of type "Added" that hold that information. Also the Reflection calls on a type were done by the ClassGraph object.
    In APRlib those Reflection calls and caching of the Reflection information are done by the ClassDefinition object. This helps encapsulate the information inside the ClassDefinition and minimizes the Reflection calls.


// Work in progress...

Phase 4

The new version of APLib differs too much already from the original one, so I decided to change the name to avoid confusion. For the time being it is going to be APRlib (The "R" is for Reflection), but I accept suggestions.
These are some of the changes from the original Java implementation:

  • In APLib, ClassGraph is a directed graph where the nodes are the names of the classes in the Class Graph and the edges describe the relations between the classes (superclass, subclass, interface implementation, etc.). It also holds hashtables to map each name to class definitions, incoming edges and outgoing edges.
    In APRlib, the nodes are the ClassDefinitions themselves and the source and target of an edges are also ClassDefinitions instead of class names. This means that once being in and edge there is no need to lookup the reference in the Hashtable to get the source or target of that edge.
  • A ClassDefinition is a wrapper around a System.Type object. It adds functionality and also minimizes the use of Reflection queries to improve performance.
  • All ClashGraph edges have now a common base class, EdgeBase. The new subclasses are:
    - InterfaceEdge ( replaces Interface ).
    - BaseclassEdge ( replaces Superclass ).
    - SubclassEdge ( replaces Subclass ).
    - PartEdge ( replaces Part ).
  • In APLib was the parser who created the different types of Strategy objects (PathDirective, StrategyGraph, StrategyCombination, etc.). First, the parser created a StrategyExpression from the string and attached the new Strategy to that StrategyExpression. The decisions of which Strategy create were made based on the string received as input.
    In APRlib there is no parser, so I took a different approach. StrategyExpression is replaced by StrategyFactory. This is a factory class that follows the "Abstract Factory Pattern" and is responsible for making the decisions on with Strategy create. It uses different "Creator Classes" for each type and all of them implement a "CreateStrategy()" method that is called when the decision is made.
  • Traversal class in APLib is now called TraversalBase in APRlib (it is an abstract class).
  • The legal keywords to be used in Strategies are in a class called StrategyKeyword as public constants.
  • The classes SourceMarker and TargetMarker that marked a StrategyGraph edge as "source" or "target" are replaced by boolean fields in the StrategyGraphEdge itself.
  • The original internal Traversal classes NodeSet and EdgeSet are replaced by external classes TraversalNodeSetBase and TraversalEdgeSetBase respectively.
  • The same is true for the internal classes NodeSet and EdgeSet in TraversalGraph. They are now called TraversalGraphNodeSet and TraversalGraphEdgeSet.
  • All the one-letter-variables are replaced now by full-length descriptive names.

Phase 3

The current implementation of DJ relies on code generated by DemeterJ to build the data structures that are used to compute the traversals and the rest of operations. This code makes use of parsing to construct the objects that define all the elements in the ClassGraph, StrategyGraph, etc.

On the other hand DJ is designed to make use of Reflection to query all the metadata information and construct the ClassGraph based on that information. Thus, with the current implementation, the following sequence of operations takes place:
(DataStructure can be ClassGraph, StrategyGraph, etc. and elements can be Node, Edge, EdgeList, etc.)

(1)DJ(Query classes metadata using Reflection) -> (2)Generate strings describing the element -> (3)Parse those strings to get the information that defines the object -> (4)Generate the corresponding element in the DataStructure.

My intention in AdaptiveTraversals is eliminate steps 2 and 3, and build an APLib based entirely on Reflection. This simplifies the model and also improves the execution speed.

These are other changes with respect to DJ:

  • Changed the name of interfaces from xxxxxI to Ixxxxx in accordance with .NET naming conventions.
  • Refactored the classes in the cg and sg subpackages to eliminate the parsing and reduce its number to the minimum necessary.

Phase 2

In this phase I converted the following from Java-style to C# style:

  • Iterators to "foreach loops" or Enumerators.
  • Java Collections without match in .NET to custom strongly-typed collections.
  • Getter-Setter methods to properties (except the ones returning arrays).
  • Constants on interfaces to Enums or Structs
  • Listeners to Delegates.
  • Use of PascalCase for method names and camelCase for fields.
  • Use of Indexers with collections when appropriate.
  • Use of Reflection and Remoting instead of ClassLoaders.
  • Reorganized the code using #regions.

Phase 1

I used the Microsoft Java Language Conversion Assistant v.2.0 to generate the C# code and then I started to fix the code manually to make it compile correctly. These are the reports that I got for the different parts of the library:
 
Maintained by Santiago Blanco