为什么 System.Design 中的许多 Designer 类都标记为内部？
我在工作中一直在为我们的产品开发一些组件，其中之一是基于流程布局面板的。
我想要做的是为其提供一个自定义设计器，但不会丢失其默认设计器（System.Windows.Forms.Design.FlowLayoutPanelDesigner）提供的功能，该设计器被标记为内部。
使用 Reflector，我想我会自己再次实现它，因为它继承自“FlowPanelDesigner”和“PanelDesigner”，所有这些都是内部的。
为什么这些类会被明确标记为内部类？是否因为它们专门供 Visual Studio 使用，因此不是“框架”代码？
另外，是否有一个更简单的选择来重新实现所有功能？
I have been developing some components for our products at work, and one of them is based off the flow layout panel.
What i would like to do is provide a custom designer for it, but without loosing the features provided by it's default designer (System.Windows.Forms.Design.FlowLayoutPanelDesigner) which is marked as internal.
Using Reflector i thought i would just implement it again myself, seeing as it inherits from 'FlowPanelDesignerand that fromPanelDesigner` all of which are internal.
Why would these classes be specifically marked as internal? Is it due to them being specifically for Visual Studio use, and thus not 'framework' code?
Also, is there an easier option that re-implementing all the functionality?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
从库中公开代码的成本很高。从框架库公开甚至更高。
Ii 强烈促使您在产品的生命周期内保持二进制（以及可能的源代码）兼容性。更糟糕的是，这些只是供应商试图使用的东西，这意味着微软违反这些类别的任何合同可能会破坏我的数百或数千付费客户使用的小部件。
破坏向后兼容性是 MSFT 历来避免做的事情（看看称为 Foo2、Foo3 的接口的数量以及称为 Blah 和 BlahEx 的方法）。
由于他们在一生中以这种方式不断地承担了相当大的“债务”，他们意识到从一开始就避免这些问题是减少未来此类问题的最便宜的方法。因此，任何新的公共 API 都必须非常有力地证明其存在的合理性。
设计时代码生成是强烈要求在软件生态系统的生命周期中进行改进的领域（查看 VS 中的部分类更改，了解该领域的重大变化，但还有许多其他较小的变化）。通过暴露严重依赖于该基础设施的类，他们将限制改变他们视为竞争优势的基础设施的范围。
因此，明智、安全的方法是不公开此类。如果不是微软这样规模和客户群的公司，我当然也会采取同样的方法。
Exposing code from a library has a high cost associayed with it. Exposing from a framework library even higher.
Ii strongly pushes you to maintain binary (and likely source) compatibility for the life of the product. Worse these are just the sort of things that vendors would be tempted to use which would mean that MS breaking any contracts on these classes would likely break a widget used my many hundreds or thousands of paying customers.
Breaking backward compatibility is something MSFT has historically avoided doing (witness the number of interfaces called Foo2, Foo3 and the methods call Blah and BlahEx).
As they have steadily incurred considerable 'debt' in this manner over their life they have realised that avoiding these issues from the very beginning is the cheapest way to reduce such problems in the future. Thus any new public apis must justify their existence very strongly.
Design time code generation is the sort of area that strongly calls for improvements over the lifetime of a software eco-system (look at the partial class changes in VS for a major change in this area but there a many other smaller ones). By exposing classes which are heavily dependent on this infrastructure they would have limited their scope for changing the very infrastructure they view as their competitive advantage.
As such the sensible, safe approach is not to expose such classes. I certainly would have taken the same approach without being a company of Microsoft's size and customer base.
我不知道，但我猜微软的答案要么是“这就是我们的制作方式”，要么是“我们希望减轻维护向后兼容性的负担”。
I don't know, but I'll guess Microsoft's answer would be either "That's just the way we made it", or "We wanted to reduce the burden of maintaining backwards compatibility."