我需要修改 JButton 的 ActionListener 中的 lambda 運算式內的區域變數，由于我無法直接修改它，所以我遇到了 AtomicInteger 型別。
我實作了它，它作業得很好，但我不確定這是否是一個好的做法，或者它是否是解決這種情況的正確方法。
我的代碼如下：
newAnchorageButton.addActionListener(e -> {
AtomicInteger anchored = new AtomicInteger();
anchored.set(0);
cbSets.forEach(cbSet ->
cbSet.forEach(cb -> {
if (cb.isSelected())
anchored.incrementAndGet();
})
);
// more code where I use the 'anchored' variable...
}
我不確定這是否是解決這個問題的正確方法，因為我已經讀過 AtomicInteger 主要用于與并發相關的應用程式并且該程式是單執行緒的，但同時我找不到另一種方法解決這個問題。
我可以簡單地使用兩個嵌套的 for 回圈來遍歷這些陣列，但我試圖根據 sonarlint vscode 擴展盡可能地降低方法的認知復雜性，并且保留這??些 for 回圈理論上會增加方法的復雜性，因此它的可讀性和可維護性。
用 lambda 運算式替換 for 回圈會降低認知復雜性，但也許我不應該過多關注它。
uj5u.com熱心網友回復：
雖然它在單執行緒代碼中足夠安全，但最好以函式方式計算它們，如下所示：
long anchored = cbSets.stream() // get a stream of the sets
.flatMap(List::stream) // flatten to list of cb's
.filter(JCheckBox::isSelected) // only selected ones
.count(); // count them
我們沒有改變累加器，而是將扁平流限制為僅我們感興趣的流并要求計數。
不過，更一般地說，總有可能在沒有可變變數的情況下總結或匯總這些值。考慮：
record Country(int population) { }
countries.stream()
.mapToInt(Country::population)
.reduce(0, Math::addExact)
注意：我們從不改變任何值；相反，我們將每個連續值與前一個值組合在一起，產生一個新值。可以使用sum()，但我更愿意reduce(0, Math::addExact)避免溢位的可能性。
uj5u.com熱心網友回復：
從理論上講，保留這些 for 回圈會增加方法的復雜性，從而增加其可讀性和可維護性。
這是明顯的馬球。x.forEach(foo -> bar)并不是“認知上更簡單” for (var foo : x) bar;——您可以將每個 AST 節點直接從一個節點映射到另一個節點。
如果一個定義被用來定義復雜性，得出一個比另一個復雜得多的結論，那么唯一正確的結論是該定義是愚蠢的，應該固定或放棄。
為了使其實用：是的，引入AtomicInteger，雖然在性能方面不會產生任何影響，但確實使代碼變得更加復雜。代碼中的簡單存在表明并發在這里是相關的。它不是，所以你必須添加評論來解釋你為什么使用它。評論是邪惡的。（它們暗示代碼不會自己說話，也不能以任何方式進行測驗）。他們通常是最不邪惡的，但他們仍然是邪惡的。AtomicInteger
保持基于 lambda 的代碼在認知上易于遵循的一般“技巧”是采用管道：
- 您撰寫了一些“形成”流的代碼。這可以像 一樣簡單
list.stream()，但有時您會執行一些流連接或平面映射集合的集合。 - 您有一個對流中的單個元素進行操作的操作管道，并且不參考整體或任何鄰居。
- 最后，您減少（使用
collect,reduce,max- 一些終止符），以便減少方法回傳您需要的內容。
上面的模型（以及另一個答案恰好遵循它）往往會導致代碼與“舊式”代碼一樣可讀/復雜，并且很少（但有時！）更具可讀性，并且明顯不那么復雜。偏離它，結果實際上總是要復雜得多——顯然是輸家。
并非所有 java 中的 for 回圈都適合上述模型。如果它不合適，那么試圖將特定的方形釘子強行插入圓孔將需要付出很多努力，并且幾乎總是會導致代碼明顯更糟：要么慢一個數量級，要么認知復雜得多。
這也意味著幾乎永遠不會“值得”將完美可讀的非基于流的代碼重寫為基于流的代碼；根據一些個人喜好，它充其量只是一個百分點的可讀性，而沒有普遍同意的重大改進。
關閉那個愚蠢的 linter 規則。它認為上述“不那么”復雜的事實，并且它顯然確定這for (var foo : x) bar;比它“更復雜” x.forEach(foo -> bar)，這一事實足以證明它的傷害遠大于幫助。
uj5u.com熱心網友回復：
我有以下添加到其他兩個答案：
您的代碼中有兩個普遍的良好實踐存在問題：
- Lambda 不應超過 3-4 行
- 除了在某些特定情況下，流操作的 lambdas 應該是無狀態的。
對于#1，考慮將 lambda 的代碼提取到私有方法中，例如，當它變得太長時。您可能會獲得可讀性，并且您也可能會更好地將 UI 與業務邏輯分離。
對于＃2，您可能并不擔心，因為您目前正在單個執行緒中作業，但是流可以并行化，并且它們可能并不總是完全按照您的想法執行。出于這個原因，最好在流管道操作中保持代碼無狀態。否則你可能會感到驚訝。
更一般地說，流非常好，非常簡潔，但有時對好的舊回圈做同樣的事情會更好。不要猶豫，回到經典回圈。
當 Sonar 告訴你復雜度太高時，其實你應該嘗試分解你的代碼：拆分成更小的方法，改進你的物件的模型等等。
轉載請註明出處，本文鏈接：https://www.uj5u.com/yidong/444334.html