A tweet by Stephanie Hurlburt brought up some memories from work I did on FDT (Development Tool for Flash)
While I was working as lead developer on FDT, I came a cross a graph visualisation library and decided to create a new view for FDT, which will visualise type dependencies of the project. We already had a full representation of the dependencies in memory, because we supported live error highlighting. Means if you change something in one file and your changes break something in another file, you directly get a feedback. So in order to make this view happen, I just needed to feed our model to the graph visualisation framework.
Here is the marketing video which revealed the feature:
As you can see from the demo, the view was fully integrated in the IDE. You can select a file in Project Explorer. And based on the type defined in the file, the view will take it as the starting point. I think we also had a link with the open editor and where the cursor was (in case of multiple type definitions in one file), but I am not sure any more.
The dependencies user will see in the view are not only the obvious ones — types of properties, inheritance hierarchy, function parameters and function return types. But also the not that obvious like method calls.
Imagine you have a class AccountManager and it has a property Account (same example as in the demo). But than you have an expression in one of your methods which looks something like this:
It means that AccountManager is not only dependent on Account, but also on User and Address. Because it uses its methods. This is also why Law of Demeter is a thing in object oriented programming.
It is sometimes hard to understand how such dependency sneaked into your type, this is why every edge in the type dependency graph has a cardinality. And if user selects an edge, it shows all symbols which are responsible for the dependency in the list view on the right side. Sadly in the video it was not presented. The list view is btw. also 100% integrated in to IDE, meaning if you double click on the list item, a text editor will open up with the responsible symbol selected.
Another feature which was demoed in the video, was displaying “parents” of the types and also an ability to collapse the children of a parent.
Every type has a parent. Classes could be declared inside of another classes or a package. And a package belongs to a source folder. And source folder belongs to a project. As you could see from the demo, the graph showed every dependency, even to the types defined in standard library, like int and Sting. Showing the parents of the type all the time made the view very cluttered. However there was a toggle which let user show/hide parents and collapse the children of the parent. This way on a real world scenario it was easy to define boundaries, by collapsing libraries or even packages which where not of interest.
Last feature which was also presented in the demo, was the package dependency graph. When user selects a package in the project explorer, all the types in the package will be analysed and the dependencies will be aggregated as package to package. The edges have cardinalities again and user can also select them to see the details.
The dependency graph work not only for outgoing, but also for incoming dependencies. Meaning you could see not only what AccountManager needed, but also who needed AccountManager.
I implemented the feature back in 2009. Sadly almost 8 years later (2017), such feature is not part of any IDEs I am working with. Well, maybe in the next 8 years something will change.