應該避免在副程式裡存取session值,而是透過主程式存取

個案:
-----------------------------
之前寫的程式, 在 IE 瀏覽器裡做開發, 發現 IE 裡的 flash 在呼叫外部的程式(例如: service.asp)時, 可以直接 access 到 browser 已取得的 session, 但改用 chrome(or firefox)時, 安全性比較高, 不能共用, 寫在外部的程式(service.asp) 裡, 有一些副程式直接存取 session, 在 chrome(or firefox)的環境下, 無法存取到正確的 session, 所以要修改成從 request 來取得. 所以之前寫的副程式們, 要重新被改寫.

如果, 一開始寫的副程式們, 在取得 session 這一段, 是透過主程式來取得 session, 從軟體工程的角度來看, 應該是可以降低這些底層的副程式們的耦合力(Coupling), 有助於提升副程式們在其他的個案下被重用(Reuse)的機會.

內聚力(Cohesion)與耦合力(Coupling)似乎已經是個系統設計的必考題，也是很基本的概念。但是在實際在系統設計上卻常被遺忘與忽略，如果在設計複雜與高度擴充的系統時，保持這樣的理念將會提高系統的維護與重用性 (Reusable)。這個原則是相當重要的參考依據，身為系統設計與開發人員，銘記在心是必要的。

結論: 應該避免在副程式裡存取session值, 而是透過主程式存取. (以上為個人觀點, 不一定正確.)


相關文章參考看看:
http://www.slidefinder.net/%E7%B5%90/%E7%B5%90%E6%A7%8B%E5%8C%96%E6%8A%80%E8%A1%93/11594726/p2

google keyword: 耦合力



舊的 code:
----------------------
sub doUplaod()
  '// 這時候直接存在 sub 裡 access session 值,
  upload_path=session("uploadPath") + "/" + filename
end sub



建議的 code:
----------------------
sub doUplaod(uploadPath)
  '// 這時候直接存在 sub 裡 access session 值,
  upload_path=uploadPath + "/" + filename
end sub

* 說明: 參數 uploadPath 不是透過 session 取得,
優點: sub 就可以被沒有 session 的副程式來使用, 只要把 uploadPath 放到 sub 的 參數即可.
缺點: sub 要多傳一個參數進去, 會比較麻煩一點點.


* 附註: 把 database 的 connection object 寫成 global 有時候也會很麻煩, 因為您寫的舊的程式碼變成必需固定有一個global 的 connection object, 當您的 app 需要處理2個 connection 時, 之前寫的程式就會不能直接使用, 所以建議您在寫副程式時, 要把 connection 當成參數傳進去, 在"某些" 情況下會比較好.