首先我申明這個詞沒有官方論證，只是我個人的乙個命名。到現在是不是有點納悶，有物件導向程式設計，面向介面程式設計，面向方面程式設計，怎麼又忽然多了乙個面向介面程式設計，不用著急聽我慢慢道來。
叫 做開發模式好像不確定，實際上主要的目的就是更快更準的了解使用者需求，讓需求更改機率盡量降低，提高開發效率。我一直在思索這個問題，到底叫做方**還是 模式，但是我又想如果這個叫做模式的話，就應該有一套輔助的設計框架，因為這個也是乙個嘗試，還需要進一步的論證和完善，這本書中我主要就是以php開發 saas應用為例，演練一下這個模式，順便會提供乙個簡單輔助開發框架，方便介面設計，就先叫做模式吧！
下邊是我個人認為值得一起的口號（原則）： 1、
精確介面描述，勝過大量使用者看不懂的需求規格說明書；
當 我們做乙個系統的時候，做使用者的需求是最難的事情，這個就不用說明理由，尤其在中國這個問題讓人頭疼，沒有行業的標準，老闆的喜愛很重要，在國外有專業的 諮詢公司，能寫出乙份詳細完善的需求說明書，但是在中國可以說是天方夜譚，因為使用者本身就不知道他自己需求是什麼樣子的？我們做系統的設計的人，想真正了 解使用者的需求那是難上加難。
我在研究模式設計的時候，也發現很多系統架構師在做「符合中國的開發模式」的命題研究，但是這個巨集偉的目標什麼時候才能實現，我希望他能早點把理論建立起來，我們再想辦法實現。
以 前做專案的時候，使用者總會告訴我，你們先設計乙個大概能操作的東西，我再看看需要什麼，那裡不對，這樣會讓很多設計人員哭笑不得，還沒有理清需求，也就是 說還沒有評估專案的風險就要開動工，這樣對軟體企業的風險很大。最近在為乙個軟體公司做it諮詢的時候，發現該公司遇見的這樣的問題更是惱火，使用者更本就 不考慮系統的安全性和程式的健壯性，做驗收的時候只看介面的操作流程，是不是符合自己的流程和習慣？
於是我就再想，如果我們工程師在做需求的時候，放棄過去報表，文件的整理，而讓我們的ui工程師和介面程式設計人員在了解大概的需求之上做出可操作的介面，讓使用者在可見的介面上提出需求，我們不斷的修改介面，以達到使用者的需求，這樣就可以避免使用者需求不明的問題。 2、
詳細介面輸入設計，勝過要求使用者提供資料字典；
以 前我們在做需求的時候，就要整理使用者的各種單據，但是往往單據上表現的資料並不能完全呈現完輸入的資料，比如乙個產品訂單的時候，他不會呈現出這個訂單相 關的合同資訊，但是在輸入訂單的時候就會有相關的合同編號，甚至還會錄入一些合同的必要資訊，比如金額。這樣我們再整理資料字典的時候就會出現麻煩，我們 要把能收集的單據全部整理再一起，再進行資料分析，整理資料字典，就在使用者完全緊密配合的情況下我們做到100%的正確也是相當有難度的。
如 果我們把這些都做在介面上，讓使用者在介面上實現自己的工作流程，他就會很清楚的告訴我們單據上的東西還會有合同上的那些必要資訊，不要問他為什麼會知道？ 這個是他的工作流程。這樣我們的介面上就是完整的使用者需求資料字典，我們在根據這些表象的資料輸入介面來分析資料字典是不是容易了很多。甚至清楚的描述了 各個實體物件之間的關係。
就上邊的例子，我們詳細分析這個案例：
訂單樣例（紙張）【order】 訂單
產品列表 數量
質量 時間
標準 厚度
(cm) 氧化
i ii
iii iv
鋁a 20
2.5
不需要
08-08 是
鋁合金b 50
1 需要
08-08 是
合同樣例（紙張）【contract】
甲方：a公司
乙方：b公司
合同內容；
合同責任；
合同金額；
付款條件；
2023年8月26日16:49:55
具 體的工作流程是市場部門簽訂合同，開始下單要生產部門，但是下單的時候合同的金額保密，所以單據上就沒有金額，每個訂單有乙個編號，市場部門的簽單人員和 老闆會根據合同找到訂單的編碼，再詢問生產部門，控制整個生產的進度。這裡就有乙個問題，合同怎麼找到訂單呢？他們目前的操作是在每個合同中增加乙個扉 頁，專門記錄生產的跟進記錄。因為還有一種情況，就是合同追加產品，比如我剛簽訂了20個產品的合同，送給我的時候，我覺得很不錯，還需要200個，就不 需要在重新簽訂合同了，在上次合同上追加200個產品，這樣合同只是增加了附件，而訂單都要重新下到生產部門。
還隱含這樣乙個問題，根據合同跟蹤訂單生產只是乙個工作，假如公司的業務非常繁忙，老闆就決定先做大單，後做小單，這樣就需要及時告訴生產部門進行調整單子生產計畫。
如果我們做需求就分為三步：
第一步：收集這兩個單據；
第二步：整理出兩個實體物件（order和contract）
第三步：分析上邊所講的工作流程，建立e-r關係模型，難度就在這裡，使用者能不能清晰的描述出自己的需求？
如果我們用介面輸入設計，也是三步：
第一步：收集這兩個單據；
第二步：做4個介面，contract輸入、order輸入、contract顯示和order顯示；
第三步：讓使用者操作，就能清楚的告訴你，顯示的時候少那些元素，輸入的時候少那些元素，也就是讓使用者需求表象化。這樣就容易很多了，目的一樣能達到，而且使用者接受度更高。 3、
不同分工的介面，勝過使用者提供業務邏輯；
要 分析使用者的業務邏輯實際上就是做use case，當然我們在需求很明確的情況下都非常好辦，有很多優秀的工具能協助我們完成，但是問題恰恰出在我們不 懂，需要和使用者不停的交流，甚至要去參加使用者的具體工作中，為了解決這個問題，就出了乙個新的辦法user story，就是系統分析人員假設很多卡片 （令牌），使用者按照自己的工作流程一步一步的拿走自己想要的卡片，系統分析人員都記錄下來，用這樣的辦法來完成use case。
上 邊的這個方法是現在比較常用的方法，但是在實際操作過程又會遇見很多客觀的因素，使用者能不能很好的配合系統分析人員的工作？而且使用者有可能出差，開會等等 耽擱。我們在做系統分析的時候更需要企業的管理層參與，但是企業的管理層都是「忙人」，所以這個方法在系統分析的時候也會遇見很多不可預知的難度。
下邊就講講我的乙個案例，做乙個網路企業的專案管理系統。說是專案管理系統，但是這個系統比較複雜，包含了人事的很多功能，還包含了crm的部分功能以及合同管理。
大 概的需求是這樣的：市場人員談專案，在專案差不多的時候會從財務部領取合同，當時專案敲定的時候就會簽訂合同（當然有合同簽訂不了），財務審合同和客戶資 料。合同一旦確定，單子就會下放到技術部門，專案經理根據合同建立專案，設立專案監督，分配工作建立任務，系統生成甘特圖。被分配到實施任務的技術人員就 會看到自己的任務，以及計畫工期，每天完成任務的時候進行跟進和反饋，專案經理進行進度監督，專案監督進行質量監督。
就 這點功能來說不算是複雜的系統，這個是多人協作的辦公系統，我們採用了b/s架構，但是我和我們的工程師進行交流的時候，就希望這個系統能有擴充套件性和通用 性在許可權這塊就做了很大改變，準備做成自定義許可權，再基於角色分配這些許可權。具體的實現到後邊再詳細做說明，這個系統的核心是客戶和合同，大家都是圍繞這 個工作展開。和幾位工程師溝通之後就決定嘗試下我們的逆向設計思維。
人員安排：
ui一位：此角色的工作就是做使用者的輸入介面了，把我們設想的介面都做了，實際上工作量很小，因為這個是乙個軟體，不需要很多華麗的和動畫做裝飾，基本都是html。
前端開發工程師一位：此角色的主要工作是重構頁面和整理js框架，這裡的重構的主要工作就是為了配合js工作，比如要給某寫元素加上id方便控制，js採用jquery框架，編寫了適合自己操作的外掛程式。
php工程師一位：此角色的工作量很小，因為前端用了很多ajax實現，配合做ajax的簡單響應。
系統分析師一位：分析系統結構和使用者需求。
由於這個專案實施的時候並沒有想到要寫此書，很多原始的資料很難找到，就些截圖，主要是方便大家理解。
面向介面程式設計的設計模式
為了避免上面的問題發生，工廠模式建議讓computer類組合乙個output型別的物件，將computer類與printer類完全分離。computer物件實際組合的是printer物件還是betterprinter物件，對computer而言完全透明。當printer物件切換到betterprin...
面向介面程式設計 工廠模式 單例模式
當與資料庫打交道，考慮到有各種各樣的資料庫，我們通常設計乙個dao介面與n個dao類，dao類實現dao介面，在處理類中定義乙個dao介面，並在配置檔案中設定這個介面使用的是哪個dao類。此種方法也叫控制反轉。當有好多介面時如userdao,categorydao,productdao時，我們通常設...
面向介面程式設計 工廠模式 單例模式
當與資料庫打交道，考慮到有各種各樣的資料庫，我們通常設計乙個dao介面與n個dao類，dao類實現dao介面，在處理類中定義乙個dao介面，並在配置檔案中設定這個介面使用的是哪個dao類。此種方法也叫控制反轉。當有好多介面時如userdao,categorydao,productdao時，我們通常設...