this?using optionals correctly 中的第 12 項不是可選文章狀態有時，我們傾向于“過度使用”東西。這意味著我們有一個東西，比如 Optional，我們到處都能看到它的用例。在 Optional 的情況下，一個常見的場景涉及鏈接其方法以獲得值的單一目的。避免這種做法并依賴簡單明了的代碼。也是一樣嗎Stream.ofNullable？我應該避免這種情況嗎：Stream.ofNullable(getHandlers(...))? ?.flatMap(Collections::stream)? ?.forEach(handler -> handler.handle(event));贊成這個？List<Handler> handlers = getHandlers(...)?if (handlers == null) {? ? return; // do nothing}handlers.forEach(handler -> handler.handle(event));
1 回答
溫溫醬
TA貢獻1752條經驗 獲得超4個贊
我認為“依靠簡單明了的代碼”的建議在任何地方都是很好的建議，不限于 eitherOptional或Stream.ofNullable.
就題中的具體選擇而言：我覺得很難說一個客觀上比另一個更簡單直白。Stream.ofNullable更簡潔，但需要您知道它的作用；顯式檢查更冗長，但如果您不熟悉s，if可能更容易理解。Stream
當向 API 引入新方法時，可以說它在某種意義上“更難”，因為不熟悉 API 方法的人會發現它更難閱讀，因為他們不知道該方法的作用。當然，人們可以反駁說他們應該知道，或者應該預料到會遇到他們不知道的事情。
所以，我基本上是說你應該使用你/你的代碼的讀者會覺得最舒服的那個。
但是，我認為這里不好的做法是getHandlers(...)首先返回 null 。Effective Java中有一項（第 3 版第 54 項，第 2 版第 43 項）關于總是返回一個空列表而不是 null。
此建議在這里非常有效，因為您處理空列表的方式與處理空列表的方式相同。
這樣做可以讓你寫：
List<Handler> handlers = getHandlers(...); handlers.stream().forEach(...);
這是客觀上更簡單的代碼。
我認為使用它會更好：
for (Handler h : getHandlers(...)) {
// ...
}因為您可以更靈活地在循環內做更多事情（例如中斷），而無需使用流（/類似流的方法）。
添加回答
舉報
0/150
提交
取消