In this topic
About consuming and extending ArcObjects
The functionality of ArcObjects can be accessed using the following application programming interfaces (APIs):
- Component Object Model (COM)
- .NET
- Java
- C++
The decision of which API to use depends on a number of factors, such as the ArcGIS product with which you are developing, the end user functionality that you are developing, and your development experience with particular languages. When working with ArcObjects, developers can consume functionality exposed by ArcObjects or extend the functionality of ArcObjects with their components. When referring to these APIs, there are differences with respect to consuming and extending the ArcObjects architecture.
Consuming the API
The APIs support consuming the functionality of the ArcObjects components; however, not all interfaces implemented by ArcObjects are supported on all platforms. In some cases, interfaces use data types that are not compatible with an API. In situations like this, an alternative implementation of the interface is provided for developers to use. The naming convention of a GEN postfix on the interface name is used to signify this kind of interface (IFoo would have an IFooGEN interface). This alternative interface is usable by all APIs; however, if the non-generic interface is supported by the API, it is possible to continue to use the API specific interface.
Since ArcObjects is developed in C++, there are some cases in which data types compatible with C++ have been used for performance reasons. These performance considerations mostly affect the internal workings of ArcObjects; hence, using one of the generic interfaces should not adversely affect performance of your ArcObjects developments.
Extending the API
Extending ArcObjects requires creating your objects and adding them to the ArcObjects architecture. ArcObjects is written to be extensible in almost all areas. Support for extending the architecture varies among the APIs and in some cases, varies among languages of an API.
The majority of differences between API support for ArcObjects revolves around data types. All APIs fully support the following automation-compliant data types. Differences occur with data types that are not Object Linking and Embedding (OLE) automation compliant.
The COM API provides the most possibilities for extending the system. The limitation within this API is with the Visual Basic (VB) language. VB does not support the implementation of interfaces that have one or more of the following characteristics:
- The interface inherits from an interface other than IUnknown or IDispatch. For example, ICurve, which inherits from IGeometry, cannot be implemented in VB for this reason.
- Method names on an interface start with an underscore (_). You do not find functions beginning with an underscore in ArcObjects.
- A parameter of a method uses a data type not supported by VB. IActiveView cannot be implemented in VB for this reason.
In addition to the limitations on the interfaces supported by VB, the binary reuse technique of COM aggregation is not supported by VB. This means that certain parts of the architecture cannot be extended (custom features is one example). In reality, the previously discussed limitations of VB have little effect on the vast majority of developers, since the percentage of ArcObjects affected is small, and for this small percentage, it is unlikely that developers will have a need to extend the architecture. Other COM languages, such as Visual C++, do not have these limitations.
The .NET API supports extending ArcObjects fully, with the one exception being interfaces that use non-OLE automation-compliant data types. See the following illustration for a complete list of all OLE automation-compliant data types:

COM and .NET APIs are only supported on the Microsoft Windows platform.
The ArcObjects Java API supports extending ArcObjects in the core areas of visualization, geoprocessing, and geodatabase management. For more information about extending ArcGIS functionalities using Java API, see Introduction to extending ArcGIS .
ArcGIS applications are rich, professional geographic information system (GIS) applications with a lot of functionality, but if viewed simply, the applications can be broken into a series of toolbars with a table of contents (TOC) and map viewing area. The desktop applications are all extended by adding new commands and tools. In a similar way, developers can build applications with rich functionality using any of the previously discussed APIs.