Component Object-Model Recommendations
When designing your component, you should consider how extensive an object model your component needs. Some components — for example, an inherited control — might not need to contain any objects, and would therefore not need an object model. On the other hand, an extremely complex component might need to manage thousand of contained objects. Here are some general recommendations to keep in mind when designing your component object models.
- When possible, expose contained objects as properties. This allows you to control access to the contained objects and validate interactions with contained objects.
- If your object needs to work with and expose an indefinite number of contained objects, implement a collection property. For details, see Collection Properties.
- If your object needs to work with and expose small, defined numbers of contained objects, implement them each as properties.
- If you do not want client applications to be able to use contained objects, set them as Friend (internal in C#) or Private. In these cases, you might want to consider using nested classes. For details, see Nested Classes in Components.
- When implementing a collection property, you must determine how much collection functionality you want to expose to client applications. If you want to expose relatively little functionality, wrap your collection in a property and expose only selected members. If you want to expose a greater amount of functionality, consider creating a custom collection class and exposing the collection directly as a property. For details about these two approaches, see Collection Properties.
- Keep it simple. Generally speaking, a simpler implementation will be faster. If accessing an item involves a series of nested references and function calls, performance will suffer and your component will be more difficult to use. Simple, well-thought-out object models make your component easy for developers and client applications to use alike.