Re: [請益] 低耦合 高內聚?
※ 引述《Elly (●A利 ●A你)》之銘言：
: 常聽到IT人在說低耦合,高內聚,小妹我也希望能作到如此...
: 但以我一個初學者,實在很難以理解,到底要如何實作呢?
: 最近,我練習作一個client-server-db架構的底層,
: 以我一個初學者的想法,
: 當然就是作一個Base Form, 讓所有表單來繼承...
: 我把每個視窗都會出現的新增、修改、審核、刪除、
: 取消刪除、退回、清除畫面....等按鈕都拉一拉,
: 以及中間放一個panel,加以配色、排版後,
: 再加上一些屬性:ex.上述按鈕各要呼叫哪些server端的method...等,
: 然後再註冊上述按鈕的事件,
: 在事件中去呼叫那些屬性設好的Method,
: 當然...我還沒能作到讓繼承的表單什麼code都不用寫,只要設一設就可以動,
: 因為每個表單總有它特別要處理的地方,
: 像是輸入的欄位,都要個別再拉,個別依狀況處理,
: 所以我又在Base Form中所有我註冊事件中
: 呼叫我為它們加上的一個[可override的Method],
: 讓繼承表單可以override實作內容...
: 另外我也花了不少時間繼承開發工具內建的輸入元件,
: 像是TextBox, Grid, ComboBox等等,再為他們加上一些功能
: 作了很久之後,
: 我覺得...好亂呀XD....
: 所以我想到了IT人常說的,
: 要作低耦合+高內聚,
: 我悟性不太好,又再去google了好幾次...
: 猜想應該是不要作一個Base Form來繼承,
: 而是將Base Form要作的事,都提出來寫成很多個小小的靜態函數,
: 再讓其它Form呼叫這些靜態函數就好了嗎?
: 但這樣感覺好像每個Form都會寫差不多code耶~有點像在複製貼上...
: 我實在很疑惑@@?
: 有人能教教我嗎?感恩啊~
低耦合、高內聚只是一種狀態上的形容，對你的學習並沒有太大的意義。
就像我們說某人看起來很幸福，但要怎麼做到跟他一樣幸福還是得研究
細節才會明白如何接近那種狀態。
回顧一下你的描述：
===========================================================
當然就是作一個Base Form, 讓所有表單來繼承...
我把每個視窗都會出現的新增、修改、審核、刪除、
取消刪除、退回、清除畫面....等按鈕都拉一拉,
以及中間放一個panel,加以配色、排版後,
再加上一些屬性:ex.上述按鈕各要呼叫哪些server端的method...等,
然後再註冊上述按鈕的事件,
在事件中去呼叫那些屬性設好的Method,
當然...我還沒能作到讓繼承的表單什麼code都不用寫,只要設一設就可以動,
因為每個表單總有它特別要處理的地方,
像是輸入的欄位,都要個別再拉,個別依狀況處理,
===========================================================
→ Elly:回1樓,我已將base form內很多東西依功能切割成小小的method 01/19 22:02
→ Elly:但很疑惑的是,我要不要將base form給砍了~裡面的method寫成靜 01/19 22:03
→ Elly:態Methods呢? 01/19 22:03
===========================================================
你現在的想法都單純在『形式』上打轉，是說選用繼承的策略包裝
出一個 BaseForm，裡面提供實作表單時需要用的的 method。或是
不需要有 BaseForm 把原本寫在它上面的方法變成 static method。
這個選擇只是單純將程式碼『集結』的形式上做改變，你沒有反映
出處理表單時應該涵含的『行為』。
因此，我一開始給予的評論就是：『設計不在於形式，而是在於行為。』
把程式碼搬來搬去的行為主要是著眼在重構，你目前的做法只能夠
稱為利用『繼承』的形式來進行一個開始實作前的重構，因為你預
先想好了哪些『零碎』的程式片段應該是一個『動作』，並將它們
一一轉化為 method。
當有人要開發新的 Form 時，就得繼承你的 BaseForm，利用一些
你提供的 method 讓整件事變得更加容易些。但是這些 method 在
你的描述上，看起來並不是必定會被後續的實作者採用，這意謂著
實作者可能會實作出跟你預想的行為有其大差距的 Form。
既然都開始規劃了個 BaseForm 了，你其實能再多想一點。
『每一位實作者的責任是什麼？』
如何透過『設計』輔助實作者滿足他應讓擔負的責任，以減少實作
過程因為疏乎而產生的 Bug 呢？你可以試想一下一個 Form 處理
的流程有哪些任務呢？當使用者輸入好內容後，它會 Submit，然
後進入『Business Logic』處理，誰該進資料庫的進資料庫，如何
讓資料回到 UI 顯示的資料回來：
*. 一個 Form 操作的基本流程是什麼？
*. 如何針對使用者提供的 input 提供 validation
*. 如何針對不同使用者提供 authentication & authorization
*. 如何規範資料庫存取的準則？
需要有完整的 Service Layer (Business Logic) 還是直接通達 DAO。
*. BaseForm 是直接綁定 UI classes 還是獨立操作的？
如果是 UI classes 要如何隔離出 user input 以便於單元測試？
這只是一些簡單地提問，也許能幫助你去思考你想要針對哪些
『重點』進行設計。無需每個主題都提供設計 (Library or Framework)，
重點在於你提出設計後，能達到防禦與進攻的需求：
:: 讓參與實作的人避免寫出基本的 bug
像是明明有加 UI Control 但沒有人去取值回來使用。
:: 讓參與實作的人強迫接受一些規範
以先前的文章，您是在金融單位工作，那麼表單的輸入裡
user input validation 就是一個重要的項目。
舉例來說，繼承 BaseForm 的人都必需覆寫 boolean validate()
:: 如何讓資料在 UI 與 Datasource 間自動地傳遞
使用者輸入資料很可能不是有空白的表單開始的，
而是先查出一筆記錄，然而以此狀態為基礎進行修改。
我們當然知道手工就是一個一個寫程式地設定上去，
但有些設計方式蠻值得參考的，像 Rails 或 Grails 那樣的方式。
我不確定你目前主要的需求是 Web App 或是 Desktop，
但他們都有現有的一些東西可以參考，Web Framework
多到不勝枚舉。而 Desktop GUI 相對是比較少的，您可
以參考 Web Framework 有的概念來實作。在我個人的經
驗中，用過比較有興有實用的大概是 Data binding framework：
JFace Databinding
http://www.vogella.de/articles/EclipseDataBinding/article.html
Swing 也有相關討論
http://stackoverflow.com/questions/2400998/swing-data-binding-frameworks
針對不同的重點去提出你的設計，即使拼湊起來四不像也
無妨。設計的感覺與經驗都是這樣一步一步演化來的。有
一點需提醒的是：注意 anti-pattern 或 anti- 的問題。
提供設計並不是為了『解決』問題，多數的情況你會發現
問題是不會被解決的，而是被轉化成不同的問題，或是切
割成容易解決的問題。當你的新設計會造成更嚴重的問題
時，就是導入了一個不良的設計了。
--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 61.231.50.105
推
01/28 11:46, , 1F
01/28 11:46, 1F
推
01/28 11:50, , 2F
01/28 11:50, 2F
推
01/29 14:07, , 3F
01/29 14:07, 3F
討論串 (同標題文章)
完整討論串 (本文為第 4 之 4 篇)：