Confused about learning the .NET ArcObjects Library Reference

[AlexanderWolf]

Hello fellow developers,

I come from the java world where documentation contains function definitions and usage information for the Class for which I look up documentation.
I have been trudging in the world of VB.NET for the past month and feel like I am only slowly making progress.
The main problem I am facing is that I don't know what each Class can actually do.
Looking up the documentation generally shows me
for Classes: which interfaces my Class implements
for interfaces: the functions that must be implemented and which CoClasses implement the interface

Comparing documentation between .NET and Java for the FeatureClass Class almost made me cry. Compare for yourself:
http://help.arcgis.com/en/sdk/10.0/arcobjects_net/componenthelp/index.html#/FeatureClassClass_Class/...
http://help.arcgis.com/en/sdk/10.0/java_ao_adf/api/arcobjects/com/esri/arcgis/geodatabase/featurecla...

If this is the norm for .NET documentation then it would mean I have to open every implemented interface and search through those functions just to get an overview of what the Class I am informing myself about can do.
Right now I am using Visual Studio 2010 and letting autocomplete inform me about the possibilities but it makes it all so difficult to get an overview.

This all leads me to one conclusion: I must be doing something wrong. Please help me with info on how to get an overview of the classes more quickly in .NET.

Thanks,
Alex

P.S. I am slowly going insane.

[NeilClemmons]

Maybe I'm different from other developers but when it comes to ArcObjects I don't think in terms of classes.  I think in terms of interfaces.  About the only time I actually think about what class I'm working with is when I need to create a new instance of it.  After that, it's all interfaces.  If you learn the interfaces then all you really have to do is look up the class you're working with to see if it implements the interface(s) that you need.  If it doesn't, then you look up the interface to see what class you need.  That's how I do it anyways.

[LeoDonahue]

Coming from a Java background myself, you are preaching to the choir.  Java ArcObjects documentation is superior to .NET ArcObjects documentation.  If the .NET docs didn't make you expand everything to see what you're looking for, it would be more useful.

About the only time I actually think about what class I'm working with is when I need to create a new instance of it

Well, considering Interfaces have no implementations, that would be alot of the time for us.  Having an instance of a class is generally the only way you can use most of the Interfaces, which is why us Java people start with classes that are concrete and then see what Interfaces a class implements.

Alex, why leave Java for VB.NET?  Was it a dare?;)

[NeilClemmons]

Well, considering Interfaces have no implementations, that would be alot of the time for us.  Having an instance of a class is generally the only way you can use most of the Interfaces, which is why us Java people start with classes that are concrete and then see what Interfaces a class implements.

Very true, you can't work with any interface without using a class that implements it.  However, when it comes to learning ArcObjects I think it's much easier to focus on tasks.  Interfaces define the functionality that is available.  Instead of trying to learn everything that a Polygon class can do, it's simpler (at least to me) to break it down into such things as "how do I set z-values on a geometry".  If you learn what functionality is provided by an interface, such as IZAware, then you've learned specific functionality that applies a good number of actual classes (i.e. not just the Polygon class).  Practically everything I do is task driven - my program needs to do A, B and C.  I ask myself what interfaces provide that?  I then look at those interfaces to see what classes I need.  It's all a matter of perspective I suppose, but for me, I think of the interfaces first.  Of course, I've been doing this for 12 years now so I do a lot of things without thinking at all 😉

[LeoDonahue]

Good points Neil,

I think it also has something to do with the Java API docs as well.  Java programmers get used to looking for classes that they are going to do something with.  In the Oracle Java API, interfaces are not all grouped together as they are in the ArcObjects Java docs.  So if I was wanting to work with a JPanel, I would look at JPanel in the API, not the Interfaces ImageObserver or MenuContainer, etc., because I wouldn't know about those before looking at JPanel for the first time.

It is definitely a different approach between .NET and Java and you get used to it in either programming environment over time.

.NET ArcObjects API lists "functionality" in the Interfaces, while Java ArcOjects API lists "functionality" in the concrete class.  By "lists" I simply mean that the docs present that information to developer.

[LeoDonahue]

Oh, Alex, not to confuse you or anything, but check this out: 
.NET IFeatureClass Interface http://help.arcgis.com/en/sdk/10.0/arcobjects_net/componenthelp/0025/0025000002qs000000.htm

Scroll down to where you see the CoClass section.  Notice how a FeatureClass and a RasterCatalog both implement the same functionality, or so it seems?  Reading this one would think that a FeatureClass and RasterCatalog have the same "addField" member originating from IFeatureClass.

However, check out the Java API for the IFeatureClass interface: http://help.arcgis.com/en/sdk/10.0/java_ao_adf/api/arcobjects/com/esri/arcgis/geodatabase/IFeatureCl...
It does not have the "addField" member.  In Java, while both FeatureClass and RasterCatalog have "addField" members, those contracts are actually declared in IClass. 

The .NET docs do not present as clear a picture as the Java docs do as to in which actual Interface the functionality was declared.

Just my opinions.

[AlexanderWolf]

Thank you Idonahue and Neil for your reassuring comments. I started working with .NET because I need to help someone extend an already existing VB.NET project. I would have loved to do this in Java if I could have. I was hoping there was a different set of API docs available but I guess I will have to do it the way described by Neil.

It is definitely a different approach between .NET and Java and you get used to it in either programming environment over time.

.NET ArcObjects API lists "functionality" in the Interfaces, while Java ArcOjects API lists "functionality" in the concrete class. By "lists" I simply mean that the docs present that information to developer.

I also think that the Java documentation is superior but that may just be because I am used to it. I will have to get used to the way its done in .NET