Почему многие классы Designer в System.Design помечены как внутренние?

Question

Я разрабатывал некоторые компоненты для наших продуктов на работе, и один из них основан на панели макета потока.

Что я хотел бы сделать, так это предоставить для него собственный дизайнер, но без потери функций, предоставляемых его дизайнером по умолчанию (System.Windows.Forms.Design.FlowLayoutPanelDesigner), который помечен как internal.

Используя Reflector, я подумал, что просто сам снова реализую его, поскольку он наследует от FlowPanelDesigner and that from PanelDesigner`, все из которых являются внутренними.

Почему эти классы должны быть специально помечены как внутренние? Это из-за того, что они специально предназначены для использования в Visual Studio, и, следовательно, не являются «рамочным» кодом?

Кроме того, есть ли более простой вариант, позволяющий повторно реализовать все функции?

Answer 1

Предоставление кода из библиотеки связано с высокой стоимостью. Экспонирование из библиотеки framework еще выше.

Ii сильно подталкивает вас поддерживать двоичную (и, вероятно, исходную) совместимость в течение всего срока службы продукта. Хуже того, это всего лишь те вещи, которые продавцы могли бы использовать, и это означало бы, что MS, нарушившая любые контракты с этими классами, вероятно, сломает виджет, использующий мои сотни или тысячи платящих клиентов.

Нарушение обратной совместимости - это то, что MSFT исторически избегает (свидетельство количества интерфейсов, называемых Foo2, Foo3 и методов, вызывающих Blah и BlahEx). Поскольку они неуклонно несут значительный «долг» таким образом в течение своей жизни, они поняли, что избегание этих проблем с самого начала является самым дешевым способом решения таких проблем в будущем. Таким образом, любой новый публичный API должен очень сильно оправдать свое существование.

Генерация временного кода проектирования - это область, которая настоятельно требует улучшений в течение жизненного цикла программной экосистемы (посмотрите на частичные изменения класса в VS, чтобы увидеть серьезные изменения в этой области, но есть и множество других более мелких) , Выставляя классы, которые сильно зависят от этой инфраструктуры, они ограничивали бы возможности для изменения самой инфраструктуры, которую они считают своим конкурентным преимуществом.

Таким образом, разумный и безопасный подход состоит не в том, чтобы выставлять такие классы. Я бы, конечно, применил бы такой же подход, если бы не был компанией с размерами Microsoft и клиентской базой.

Answer 2

Я не знаю, но я предполагаю, что ответ Microsoft будет: «Это так, как мы это сделали», или «Мы хотели уменьшить бремя поддержки обратной совместимости».