How do you learn a class hierarchy quickly?

Question

Hi,

Something I don't enjoy about programming is learning a new API. For example, right now I'm trying to learn Windows Identity Foundation. Its frustrating because I'm going to spend the bulk of the time learning how a few classes work and actually only write several lines of code.

In .NET, there are so many types that I seem to spend more time hunting around in msdn for a class than writing code. It also interrupts my workflow while I'm working because I have to type a little bit than look something up.

Obviously, I don't have to do this for the basic classes. Whenever new things come though there is definitely some looking up to do. Then I often don't reuse that class enough to really review it or bring it into action.

I'm wondering if anybody out there has a found a way to memorize (or look up more efficiently) these object model hierarchies?

Answer 1

Drawing some UML diagrams and posting them next to your monitor can help. Otherwise, I think the only way to really get new classes' interfaces into your head is to use them a lot.

Unfortunately, spending more time looking at docs than writing code is a typical feature of modern programming environments.

Answer 2

The idea that you can completely learn a new API died a long time ago, probably with Windows 3.0. The Windows API became so complex that it really was beyond the ability of most of us to learn it all, in the way you could for example learn all UNIX system calls. and there was no need - online documentation, easily searchable, made the learning unnecessary.

Of course, what you do need to know is how an API (or a class library) is organised, and what its capabilities are, but there is no sense in learning what the third parameter of function call X is.

Answer 3

Usually I don't bother learning the API as much as trying to understand the broad concepts of what the API is doing & how it goes about doing it.

So, typically start off with the high-level blocks of what the API does (usually in the documentation) & then target what you want to get out of the API & get it working with those aspects.

Yes, there will be a back & forth between the documentation & code for sometime, but as you get more comfortable with the API, you will start noticing patterns & style of the code & the other areas of the API will come more naturally to you (assuming it is a well design API :)

HTH.

Answer 4

I was in your position as well long time ago when I learned Java and its Collection classes (or SWING, or AWT for that matter).

Here are a few steps I did and the outcome of those steps:

• Didn't bother to take notes, keep on using it => only remember the most used class
• Take an unorganized notes => same result, remember the most used class
• Simple class diagrams => improvement, but incomplete
• Simple class diagrams but complete with sub-classes organized it per component (package in Java) => Jackpot!

Few more advises:

• Eliminate deprecated classes
• Find a symbol to mark a class is thread-safe (put a TS or something)
• You could omit the least-used sub-classes (maybe) as you go along with your adventure

An example of a simple class diagram:

• http://www.ged.fi/DesignPatterns/AWT.gif
• http://www3.ntu.edu.sg/home/ehchua/programming/java/images/IO-input-output-streams.png

Compare to this (not-so-simple):

• http://www.owlnet.rice.edu/~comp212/08-spring/lectures/30/reader.png

Hope that helps.

Ed

Answer 5

Damn, I just thought it was me getting older !!!

I write Java code using JMS, EJB, JNDI, JDBC, JSP, Servlet, Struts, Struts, JTA, Swing, POI, GWT, GAE, JDO, IBM MQ MQ, JNI, XML, SAX, DOM, C++, WIN32 as well as our own class libraries and probably some more than I can not remember.

When I need to switch between technologies it is very hard to remember all the APIs. Some of the tools that are used now are so superior that it is possible to start a new project using one of the new technologies.

• Eclipse and Visual Studio both have autocomplete.
• Google is a big help - Use it daily.
• online documentation.

In addition we create out own work-aids, that is to document step by step procedures on how to do something i.e. merging a branch into version control, deploying to a platform. We keep these items in a Wiki for our group.

Answer 6

Nothing specific to offer here as an answer.

It is a necessary part of being a programmer. You can however choose to be very picky in the frameworks that you decide to use.

A good framework

• is easy to pickup and use without documentation. It just works as you expect it to work
• still has great documentation inspite of bullet#1.
• is minimalist. Least amount of code/classes/methods to get the job done.

However there are times where you do not have a choice ; in which case the only thing is to get down n dirty in the trenches. Start with sample code - test apps - learn from people who have already been there and done/blogged that.

Answer 7

Yes, remembering all those APIs is a concern for me too...

My 2 cents (beside keeping online documentation around) is to write test suite code that use the functions I want to learn. The point is that I believe the best way to understand some API is to make it work, if you just read it you can't really be sure you understood it the right way. And having to make things works you can usually sort between what parts are necessary to understand (the strange thing is that the "hard" part is quite often about details of setup) and what parts you can leave for later. I lerant a new drawing library this way not long ago and I havn't tried yet every drawing primitives...

I write this test code as I do for any unit test in my programs, try to keep it simple and easy to understand. These tests become part of my personal online documentation and I copy paste and adapt it when necessary.

Obviously I can't test everything that way, but trying some typical cases without the pressure of the ongoing project is usually a great help to understand a new API, and I use to exchange those test suite with my co-workers.