CardLout API addLayoutComponent ()

Question

Меня немного смущает логика, используемая для получения текущего API для addLayoutComponent().

Есть два метода, один из которых принимает строку, а компоненти другой, который принимает объект и компонент (но завершается с ошибкой во время выполнения, если этот объект не является строкой).

Однако устаревшим является тот, который принимает строку, а не тот, который принимает объект,На мой взгляд, это неправильный способ - почему бы не оставить типобезопасный метод, который принимает строку, и исключать другую?

И, исходя из этого, лучше в этом случае использовать устаревший методи подавить предупреждение, когда оно приходит с гарантией типа сейф?

Answer 1

Я полагаю, что это связано с обратной совместимостью и новыми методами, введенными LayoutManager2.

Изначально все ограничения для компонентов были закодированы как строки, "CENTER", "EAST" и т. Д.Для CardLayout имело смысл использовать эти строки для имен, таких как "SETTINGS_CARD", "MAIN_CARD" и т. Д.

In пришел LayoutManager2, который был переработан LayoutManager.Во второй версии они поняли, что хотят учесть и другие типы ограничений, такие как GridBagConstraints и т. Д.

Итак, CardLayout делает то, что говорит: "ХорошоХорошо, я пойду с этими новыми причудливыми методами, но все равно буду полагаться на строки, потому что мне больше ничего не нужно ".

Поскольку версия String тогда стала излишней, они решили отказаться от нее.(Это было бы моим предположением по крайней мере.)

И, исходя из этого, лучше в этом случае использовать устаревший метод и подавить предупреждение, когда онопоставляется с гарантией безопасного типа?

Использование устаревших методов, на мой взгляд, эквивалентно «Я знаю лучше, чем разработчики Sun / Oracle API»..Другими словами, я бы держался подальше от устаревших методов.(Кроме того, другие программисты будут удивляться, почему в вашем коде есть @SupressWarning.)