Designing managed, object oriented software is hard and designing it to fit with other managed libraries outside of your direct control is even harder. The problem is exacerbated by the fact that most your functionality has been exposed in an unmanaged way for years. There is considerable code, design experience and most importantly, faithful customer’s hard learned knowledge invested in the legacy design. What parts of your libraries should be managed? How does this interoperate with Com classic and other unmanaged functionality? How does this fit into the overall Microsoft strategy? What will impress your customers about a managed design?
This document will not address all these issues. Instead we define a set of guidelines as a way help class library designers more fully understand the trade-offs of different solutions. “Rules are made to be broken” as the saying goes, and we understand that there are situations where it is necessary to stray from these guidelines. However, our hope is to force designers to make an explicate decision to violate these guidelines and for these violations to be rare and not far from the spirit of this document.
A well-designed managed class library is:
Consistent Similar design patterns across libraries
- Predicable- Easily discoverable functionality. Typically only one way to perform a given task.
Web centric - Designed with cross context, cross process and cross machine execution in mind
- Callable from semi-trusted code.
Language neutral - Functionality accessible to many different programming languages