"David Wilkinson" <email@example.com> wrote in message
Aren't "encapsulation" and "convenience to the caller" on the same side
here? It's "lazy implementer" that is on the other side, no? :)
Seriously, if I decide to move a field from one property page to another,
I shouldn't have to change the client code.
David, I guess the core of the code goes into the property pages, not the
sheet. For example, in the case of wizard mode, the next/previous page is
determined by the active page, not the sheet, when the Next/Back button is
clicked. So there is precious little of value in any CMyPropertySheet
Also, it doesn't save the client that much by having it. The client needs
to add the files for all the pages into the project, so already it's not
like you're having one reusable object if you try to expose a derived sheet.
Still, I get the point of what you're trying to do. In fact, in rare cases,
I have created a CMyProperySheet class when the pages that got added varied
depending on some condition. Normally, though, the implementation details
negate much of the encapsulation benefit, and I just don't think it saves
the client enough to warrant managing a CMyPropertySheet class.