One of the exercises I'm going through now is scrubbing our API and taking a hard look at types marked as public and trying to decide "does it really need to be public." While on first blush, you can
What I'd love to get from folks are answers to the following questions:
Looking forward to your thoughts!
1) StateMachineDesigner. I want to override some methods and not recreate all. I had to use FreeformActivityDesigner. I´m hosting the designer into my application and created state machine activities with more usability to create workflows. My final user can create workflows.
2) Why not public classes?
Just last week I needed to use the private InvokeWorkflowDesigner to display a custom InvokeWorkflowActivity on a State Machine design surface. I found that it was applied to the InvokeWorkflowActivity at runtime in both a tricky and inconsistent way.
Why not public classes?
> We have a pretty high cost for any public type that we ship (we have to document it, clear it through a more rigorous set of API reviews, etc), as well as a high longer term cost, we don't want to make something public if we think we will change or improve it in the future. Also, if we don't think we've got quite the right design, but we have something that works for the release, we would think about making it internal.
The problem with a complex designer like StateMachineDesigner is that you can't insure that there isn't a tight coupling to the underlying activity type. This is why StateMachineDesigner (and related types are sealed)
@philipwolfe, I'd love to hear more about this.