在兩周前的文章中，我們使用物件導向程式設計解決了問題：我們使用物件對問題空間進行建模。 為了使物件與另乙個物件進行通訊，可以使用dispatch()方法。
這是《程式設計風格練習》重點系列的第 9 個帖子。其他帖子包括：
以程式設計風格介紹練習
以程式設計風格進行練習，將內容堆疊起來
程式設計風格的練習，kwisatz haderach風格
程式設計風格的練習，遞迴
具有高階功能的程式設計風格的練習
以程式設計風格進行練習
以程式設計風格進行練習，回到物件導向的程式設計
程式設計風格的練習：地圖也是物件
程式設計風格的練習和事件匯流排
反思程式設計風格的練習
面向方面的程式設計風格的練習
程式設計風格的練習：fp＆i / o
關聯式資料庫風格的練習
程式設計風格的練習：電子**
併發程式設計風格的練習
使用hazelcast以程式設計風格進行練習
mapreduce樣式的練習
程式設計風格的練習總結
還記得網路無處不在嗎？ 圖形使用者介面已經是一回事。 處理使用者互動的一種很好且廣泛的方法是-現在仍然是-事件驅動程式設計：它已被廣泛用作觀察者設計模式。
觀察者是對dispatch()方法的可行替代方案。 主要區別在於，通過傳送訊息，沒有返回值。
最終的課程模型如下所示：
該模型以及下乙個模型均來自原始的python解決方案。 對於kotlin，我剛剛新增了型別。
順序圖是：
與以前的設計最重要的區別是：不再有dispatch()方法。 結果，也沒有返回值，但是在圖的末尾。
請注意，最初的設計必須不惜一切沒有返回值！ 這樣做的原因是它只列印了單詞frequency。 因此，不可能輕鬆進行測試。 因為我的要求之一就是確保實現正確，所以我更改了設計，以實際返回字頻圖作為值。
事件處理程式只是乙個高階函式，可以像其他任何型別一樣傳遞該函式。
在上述設計中，類將其方法註冊為其他類的高階函式， 例如 ，在wordfrequencycounter的init塊中：
關於事件處理程式，有幾個問題要解決：
定購 註冊事件處理程式很容易：只需提供具有正確簽名的函式，然後就可以使用。 但是，事件處理程式是由事件觸發的，事件的順序可能不同於需要處理事件的順序。 請注意，儘管對於同步訊息傳遞而言並非如此（在這裡就是這種情況），但與直接api呼叫相比，仍然很難推理。
為了從訂購中受益，可以將事件處理程式儲存在不同的「儲存桶」中。 儲存桶可以儲存不需要訂購的處理程式。 到那時，可以從這些儲存桶中呼叫處理程式，從「儲存桶1」開始，然後是「儲存桶2」，依此類推。在上面的設計中，有3個儲存桶：乙個用於初始化處理程式，乙個用於工作處理程式，以及
儲存 在python示例中，將處理程式儲存在不同的儲存桶中只是按照它們應有的順序呼叫它們。 在kotlin中，還需要考慮型別：
描述 型別
initialization event handlers consume something
(string) → unit
work handlers run by changing their internal state. neither input nor output is necessary.
() → unit
the single end handler needs to provide the word frequencies
() → map
對於當前的問題，lambda型別彼此相容。
在現實世界中，情況可能並非如此，因為會有許多處理程式。 因此，簽名將需要更加通用，並且必須進行強制轉換。
呼叫中
僅僅儲存處理程式並不是終點：在某些時候，它們需要被呼叫。 如上所述，有些返回乙個值，而有些則需要乙個引數或多個。 例如，讀取文字樣本需要檔名。 因此，以下**：
class
datastorage(:
wordfrequencyframework
,private
valstopwordsfilter
:stopwordsfilter)}
private
funload
(filename
:string).
filter
.map
(string
::tolowercase)}
// abridged for readability
}
stopwordsfilter類中。 它還會載入乙個檔案-停用詞檔案-但檔名未對其進行引數化。 但是，由於需要將其儲存在同一儲存桶中，因此需要接受string型別的忽略引數：
class
stopwordsfilter(:
wordfrequencyframework)}
private
funload
(ignore
:string
)// abridged for readability
}
事件驅動程式設計遭受乙個大問題：複雜性。 雖然在我們的簡單練習中，它是很容易管理的，但是隨著類數的增加，它可以swift公升級。
我們有兩個類，並將它們描繪為節點：它們之間可以有一條邊。 在三個節點的情況下，計數為3。除此之外，它還會根據此表增長：
節點數
邊數 213
3465
10615……n
n * (n - 1) / 2
可見，快速進行事件處理的推理變得不可能。
在某些情況下， 例如
gui，事件驅動程式設計是一項重要資產。 在這種情況下，事件傳送類，事件接收類的數量以及它們之間可能的關係非常有限。 一旦後面的計數增加， 觀察者模式就會變得非常複雜，因為每個觀察者都需要引用每個主題。 在下週的帖子中，我們將研究該問題的可能解決方案。
這篇文章的完整源**可以在github上找到。
翻譯自:
程式設計風格的練習，遞迴
本週的帖子將回到基礎知識，因為限制是使用遞迴 電腦科學中的遞迴是一種解決問題的方法，其中解決方案取決於對同一問題的較小例項 而不是迭代 的解決方案。該方法可以應用於許多態別的問題，並且遞迴是電腦科學的中心思想之一。維基百科 遞迴 computer science 這是4在程式設計風格焦點series...
使用遞迴函式重寫程式設計練習8 程式設計風格的練習，遞迴
使用遞迴函式重寫程式設計練習8 本週的帖子將回到基礎知識，因為限制是使用遞迴 電腦科學中的遞迴是一種解決問題的方法，其中解決方案取決於對同一問題的較小例項 而不是迭代 的解決方案。該方法可以應用於多種型別的問題，而遞迴是電腦科學的中心思想之一。維基百科 遞迴 computer science 這是4...
關於事件驅動程式設計
關於事件驅動程式設計 全世界最熟悉事件驅動的程式設計師應該就是前端工程師了,不管是桌面前端還是web前端都是世界上最熟悉事件驅動的,以web前端為例,我們作業面可以不去想什麼物件導向程式設計,什麼jquery框架咋用,但是為按鈕,為頁面元素新增相關事件操作肯定是不可缺少的,而web前端的事件處理機制...