DIY迷你郵件用戶端的開發結束了,現在完全可以Shift+Delete掉這個工程了。享受這個過程已經完整的進行完了,剩下的問題應該算是總結這個工程。
1. 關于測試和實驗
實驗: 經常會面臨一個問題就是要實作某一功能,但是有不确定能否一次性就能夠實作,這時候就得停下腳步,做一些較為簡單的例子,進行技術上的實驗,通過的簡單的實驗可以節省時間,并且有利于技術的确認,增強開發信心。
測試:測試應該是伴随整個開發過程的,而且非常有必要将測試深入,嚴格的滲透到我們的開發過程中去。每一個子產品就要存在相關的測試代碼,并且確定已經完成的部分能夠直接作為成品內建到項目中。
體會:保留測試代碼有利于複查和實時測試
2.提取共同,抽象業務
面向對象的聖經可是絮叨的像祥林嫂一樣被念叨,然而不正真感受抽象的重要性,是很難懂得其中的智慧。
PS:在起初設計這個郵件發送的時候同樣使用了政策模式,可是最後發現不是這麼回事,因為沒一份郵件都有一個共同點,郵件伺服器,使用者名,密碼,主題,聯系人等。對于普通郵件和附件郵件的差別也僅僅在附件方面處理有所不同而已。
抽象出了嚴重的問題,導緻整個工作進展停滞不前,不停的改動,組織最後還是需要足夠的魄力來個Shift+Delete結束過多的糾結,這樣就有了後面的事了。學習了一下commons-email-1.x的實作思路,重新對發送郵件進行了包裝,這樣解決了不同類型郵件的發送問題,收件人電子郵件位址加載問題。
編碼:使用EmailContext類對其進行了相應的處理。
public class EmailContext {
private Map<String, String> setMap = null;
private List<String> contactsList = null;
private Map<String, String> contentsEmail = null;
private MultiPartEmail mutEmailObject = null;
private SimpleEmail simEmailObject = null;
private File[] attactFiles = null;
/**
* 擷取發送郵件執行個體對象
*
* @param setMap
* @param contactsList
* @param contentsEmail
* @param attactFiles
*/
public EmailContext(Map<String, String> setMap, List<String> contactsList, Map<String, String> contentsEmail, File[] attactFiles) {
this.attactFiles = attactFiles;
this.setMap = setMap;
this.contentsEmail = contentsEmail;
this.contactsList = contactsList;
if (this.attactFiles != null) {
mutEmailObject = new MultiPartEmail();
}
if (this.attactFiles == null) {
simEmailObject = new SimpleEmail();
}
* 發送電子郵件
* @return String
public String sendEmail() {
String result = "發送失敗";
try {
if (mutEmailObject != null) {
setMultiPartEmailMessage();
result = mutEmailObject.send();
}
if (simEmailObject != null) {
setSimpleEmailMessage();
result = simEmailObject.send();
} catch (EmailException ex) {
Logger.getLogger(EmailContext.class.getName()).log(Level.SEVERE, null, ex);
JOptionPane.showMessageDialog(null, result, "提示", JOptionPane.INFORMATION_MESSAGE);
if (!result.equals("發送失敗")) {
result = "發送成功";
return result;
* 設定帶附件發送郵件資訊
private void setMultiPartEmailMessage() {
/**
* 設定發件人資訊
*/
mutEmailObject.setAuthentication(setMap.get("userName"), setMap.get("userPwd"));
mutEmailObject.setHostName(setMap.get("hostName"));
mutEmailObject.setFrom(setMap.get("from"));
JOptionPane.showMessageDialog(null, "提示", "發件人資訊加載失敗", JOptionPane.INFORMATION_MESSAGE);
* 設定收件人資訊
for (int i = 0, j = contactsList.size(); i < j; i++) {
try {
mutEmailObject.addTo(contactsList.get(i));
} catch (EmailException ex) {
Logger.getLogger(EmailContext.class.getName()).log(Level.SEVERE, null, ex);
JOptionPane.showMessageDialog(null, "提示", "聯系人資訊加載失敗", JOptionPane.INFORMATION_MESSAGE);
* 設定發送附件資訊
EmailAttachment attact = null;
for (int i = 0, j = attactFiles.length; i < j; i++) {
attact = new EmailAttachment();
attact.setPath(attactFiles[i].getAbsolutePath());
mutEmailObject.attach(attact);
JOptionPane.showMessageDialog(null, "提示", "附件加載失敗", JOptionPane.INFORMATION_MESSAGE);
* 設定郵件内容資訊
mutEmailObject.setSubject(contentsEmail.get("theme"));
mutEmailObject.setMsg(contentsEmail.get("contents"));
* 設定發送郵件資訊
private void setSimpleEmailMessage() {
simEmailObject.setAuthentication(setMap.get("userName"), setMap.get("userPwd"));
simEmailObject.setHostName(setMap.get("hostName"));
simEmailObject.setFrom(setMap.get("from"));
JOptionPane.showMessageDialog(
null, "提示", "發件人資訊加載失敗", JOptionPane.INFORMATION_MESSAGE);
simEmailObject.addTo(contactsList.get(i));
JOptionPane.showMessageDialog(
null, "提示", "聯系人資訊加載失敗", JOptionPane.INFORMATION_MESSAGE);
simEmailObject.setSubject(contentsEmail.get("theme"));
simEmailObject.setMsg(contentsEmail.get("contents"));
}
抽象不是一蹴而就的,剛開始就沒能高瞻遠矚的看到這一點,以緻後面才有了一個反反複複的疊代的過程,自然也好受教訓了,而且是曆曆在目的。
3.發送方法如此的消瘦
/**
* 發送電子郵件
*
* @param evt
*/
private void sendMailActionPerformed(java.awt.event.ActionEvent evt) {
List<String> contactsList = getContactsList();
Map<String, String> setMap = getMailSettingInfor();
Map<String, String> setContentsMap = getMailContents();
EmailContext ect = new EmailContext(setMap, contactsList, setContentsMap, attactmentsFiles);
String result = ect.sendEmail();
statusInforLab.setText(result);
}
在發送方法中基本上看不到判斷政策的代碼,普通的方法調用,這回算是回歸本相了。
寫到這,文字上的總結也應該告一段落。關于如何抽象,如何組織,如何設計,如何高瞻遠矚的看到所将要經曆的過程,一大堆的疑問還待通過更多的眼見的,耳聽的,手動的,試驗過的經曆一一解答。
本文轉自 secondriver 51CTO部落格,原文連結:http://blog.51cto.com/aiilive/1063972,如需轉載請自行聯系原作者