決定什麼方法/函數應該/不應該做

Question

我希望得到什麼應該被包含在一個方法或函數的一些意見。

比方說，我有一個功能的工作是在一個論壇上的回覆發送電子郵件通知。假設我使用了一個Mailer庫來處理所有實際發送SMTP消息的細節，並且我已經抽象出諸如body之類的東西作爲模板，To，From，Reply-To字段顯然都是變量，並且存在還有與所述用戶已經訂閱的論壇帖子相關的帖子ID。

如何這些變量的許多人會在你作爲參數傳遞？一系列參數？您是否只需傳入用戶名和帖子ID，並在該函數中使用另一種方法（如果在同一個類中）或函數來檢索所需的詳細信息（如電子郵件地址，用戶名，帖子標題等），或者使函數更脆弱，更不容易被重用作一般郵件函數/方法。

我知道有很多的，這是主觀的「依賴」，但我感興趣的思維過程去後面做決定這種或那種方式。

Answer 1

設計類和方法時應用Single Responsibility Principle。基本思想是一個類/方法應該只有一個改變的理由。記住這個和其他SOLID principles和GRASP patterns，你可以回答你自己的問題。

Answer 2

我可能會加載一個幫助類實例，它封裝了完整定義電子郵件，To，From，cc，主題，主體，附件向量以及返回結果所需的所有內容所需的所有內容 - 成功/失敗布爾值，錯誤消息字符串和一個事件，在完成時用助手實例作爲參數調用。然後我會用這個實例調用emailer函數。然後電子郵件發送者可以隨意發送電子郵件。它可以自己完成郵件，也可以將它排隊等待另一個線程或進程，稍後在郵件完成時觸發事件（或者當然，失敗:)。當事件觸發時，處理程序可以檢查發生了什麼，並採取適當的行動 - 稍後重新發送，排隊等待記錄器，排隊等待GUI顯示或者將其銷燬。