Chapter Summary

---

COM interfaces can return simple data types, and often do just that. Many times it is desirable to allow the client to obtain a batch of data from the object it is working with. On the simple side of COM development, we have arrays, safe arrays, interface pointers, and custom UDTs. As we create interface methods using these items as parameters, we allow our COM clients to reduce round trips, and therefore speed up communications.

COM enumerators provide a pattern that allows a client to obtain batches of items in a manner appropriate to the client. Using Next(), the client may ask for a number of subobjects from the container. Reset() and Skip() allow the client to traverse the internal list, while Clone() allows the client to "remember" the current enumerator for future use.

While the enumeration pattern is great for C++ solutions, a raw IEnumXXXX interface will not work in the world of VB and/or VBScript. To expose a set of subobjects that all language mappings can get their hands on, you will need to develop COM collections. This pattern provides the Item(), Count(), Add(), Remove(), and _NewEnum members to allow clients to operate on a set of subobjects, as well as add and remove items at will.

As this chapter has shown you, ATL does provide some support for both COM enumerations as well as COM collections, and as long as you can stomach the maze of necessary templates, creating sophisticated object models can actually become a satisfying experience.

---