-
1 # 井151276607
-
2 # 葡萄城GrapeCity
我就非常喜歡寫 stream。
for 迴圈裡複雜的超過 5 行的邏輯,需要單獨寫函式,所以也不會允許在 map 裡寫超級複雜的 for 的邏輯。超過這些行數的程式碼段,即便寫在 for 迴圈裡,使得一個函數里一大堆 for 迴圈,同樣不好讀。所以我更推薦函式多,而每個函式行數少。
至於為什麼推薦 stream,我覺得 stream 非常適合抽象思維去解決業務,而且我們就算做 CRM,ERP 等業務系統,我,至少我自己,對執行中的演算法複雜度和空間複雜度都是很看重的(並且我們不允許 MySQL 的 join)。所以經常在業務邏輯中用陣列,雜湊表,樹,對我來說,後端的資料都是各種 map filter distinct 等抽象而來的,而且寫起來很有數學+抽象+邏輯思維。這一點上,我非常喜歡 stream。並且 stream 的一些特性也非常好用,比如保持原有的順序。
況且我非常喜歡函式式的思維,無論是在業務開發,還是 AI,還是策略開發,還是運維各個領域,甚至到架構,函式式的思維也非常有用,甚至是非常有意義的。比如 serverless,有沒有想過,在底層邏輯上,這兩著之間有共同之處呢?Linux 的 terminal 的 pipeline,其實也和 stream 很像。
這是我喜歡用 stream 的邏輯。
-
3 # 烏氏危言
我不喜歡用。工作了幾年發現,技術技巧還是得選簡單實用的。能if,for解決,就不要用stream,lambda
-
4 # 重陽可可
閣下說的應該是集合類的流式處理,而不是檔案流吧!
1.流式處理從思維的角度來說那就是通暢,可以不需要思維阻塞地一直寫才去,有一種看爽文的感覺,如果沒有流式處理,那麼就需要不停地打斷思路遍歷集合進行處理,程式碼是又醜又很難看懂!
2.最喜歡流式處理的應該是資料開發類的程式設計師,很多資料的處理工作很複雜,分步驟,需要不同的處理邏輯,適用流式處理就可以把每一個步驟當成流的一個操作節點處理,方便!
舉例:
1.如果寫過mapreduce的都知道,常規寫法可能需要寫一個迴圈,超級複雜,如果使用流就可以寫成:(sparkstreaming舉例:)
# 統計詞頻
counts = lines.map(lambda x:x.strip())\ #1.去除首位空格 .flatMap(lambda x: x.split(" "))\ #2.根據空格分出每一個詞 .filter(lambda x:x not in stop_words) \ #3.過濾掉停用詞 .map(lambda x: (x, 1)) \ #4.給每一個詞標記1 .reduceByKey(add) #5.統計求和
.sortBy(lambda x:-x[1]) # #排序
透過一個流式的處理就簡單完成了
1.java的一個數據處理流程舉例
List<Entity> entityList = xxxx;
MapFrame<Object,Double> groups = ListFrame.fromList(entityList )
.handle("value=format(value,2)") //1.列表實體的value保留兩位小數
.handle(entity->entity.getName()==null,"name=""") //2.name為空變為""
.handle(entity->entity.getValue()==null,"value=0","value=value+2") //3.value不為空+2
.handle("name=replace(name,"#","")") //4.替換#
.handle("percent=double(value)/"+sum) //5.計算百分比
.groupBy("name").sum("percent"); //6.分組統計
上面的過程在不寫for迴圈的條件下就流式處理完了,僅僅從寫那一刻的感覺來說就很通暢
再見
-
5 # 獨釣一江秋
不確定您問的是不是c++的stream流,參加工作後你總有機會遇到它的,它的作用分場景有很多種,
1.型別轉換,就是其它任何型別向字串轉換。
2.拼裝字串時,但是成員又都不一定是字串,用它就方便。
3.可以過載輸出流函式針對自定義結構定製化輸出到流中。
4.檔案stream是可以直接操作讀寫檔案的。
流可以理解為管道,進入管道輸出是統一的字串,輸出時又可以根據內容來轉為想要內容型別。邏輯統一化處理。
回覆列表
你確信,你正確的理解了stream 機制的意義?
1、不是stream 流,而是stream(流),或者是流(stream)。這樣思維才順暢。
2、寫專案找不到用流的地方嗎?你是舉著錘子找釘子嗎?流,是一種連貫的行為、表現、思維、做為的抽象模式。要在專案中識別出像“流”類似的規律,嘗試用“流”規範它。如果模糊的問題一下子清晰起來,恭喜你,
3、看看,能比較出與其他解決問題的“範型”的優劣嗎?