我对用于到达当前 API 的逻辑有点困惑addLayoutComponent()
。
有两种方法,一种采用字符串和组件,另一种采用对象和组件(但在运行时失败,除非该对象是字符串。)
但是,不推荐使用的是接受字符串的那个,而不是接受对象的那个。在我看来,这是错误的方法 - 为什么不保留采用字符串的类型安全方法并弃用另一个?
然后,在这种情况下,使用不推荐使用的方法并在带有类型安全保证的情况下抑制警告会更好吗?
我对用于到达当前 API 的逻辑有点困惑addLayoutComponent()
。
有两种方法,一种采用字符串和组件,另一种采用对象和组件(但在运行时失败,除非该对象是字符串。)
但是,不推荐使用的是接受字符串的那个,而不是接受对象的那个。在我看来,这是错误的方法 - 为什么不保留采用字符串的类型安全方法并弃用另一个?
然后,在这种情况下,使用不推荐使用的方法并在带有类型安全保证的情况下抑制警告会更好吗?
我相信这是由于向后兼容性和LayoutManager2
.
最初,组件的所有约束都被编码为字符串、"CENTER"
、"EAST"
等。对于 aCardLayout
来说,将这些字符串用于名称是有意义的,例如"SETTINGS_CARD"
等"MAIN_CARD"
。
进来了LayoutManager2
,这是对LayoutManager
. 在第二个版本中,他们意识到他们也希望允许其他类型的约束,例如GridBagConstraints
等。
所以,CardLayout
它的作用是它说:“好吧,我会使用这些新奇的方法,但我仍然会依赖字符串,因为我不需要其他任何东西”。
由于该String
版本随后变得多余,他们选择弃用它。(至少这是我的猜测。)
然后,在这种情况下,使用不推荐使用的方法并在带有类型安全保证的情况下抑制警告会更好吗?
在我看来,使用不推荐使用的方法,等于说“我比 Sun/Oracle API 架构师更了解”。. 换句话说,我会远离弃用的方法。(除了其他程序员会想知道为什么@SupressWarning
你的代码中有一个。)