（今天寫的東西，只是我的個人一些不太成熟的看法。有增減的內容，我會盡量的修改我的理論，呵呵。）
首先，什麼是介面呢？介面在對於乙個做軟體的人來說，其實是無處不在。
軟體系統會分成各個模組，各個模組間的聯絡，我就將之定義為一種介面。例如資料庫與前端介面的介面。
各個軟體系統之間為了符合客戶要求，經常需要有交流，以方便客戶操作，避免將類似操作重複進行。例如，erp系統與crm之間資料交流的介面。
軟體與硬體的連線也有介面，甚至是不少硬體介面。例如，串列埠通訊的介面等。
假如再細化，對於oo設計來說，各個物件與對外交流的輸入輸出，也是介面。
正因為介面的廣泛性，我考慮了一些通用性的介面設計方法。
對於oo設計來說，乙個類的具體設計，怎麼設計乙個比較好的輸入輸出介面是乙個學問，也是乙個被人廣泛研究的學問。具體的建議我就不說了，但是有不少可以借用到別的介面設計中。
介面的資料流向：介面有分單向，和雙向。通常的介面，都會有輸入和輸出，我一般會把輸出作為乙個push操作，輸入作為乙個pull操作。
單向資料介面就有乙個方向性，一端是資料接收方，一端是資料傳送方。我個人認為乙個典型的硬體例子就是感測器。乙個比較典型的例子是b/s架構。乙個主要是資料輸入功能，乙個是接收資料並處理。（當然，我也知道，現在不少b/s架構的mis系統，brower還完成乙個輸出顯示的功能，有了這個功能，也可以算做是乙個雙向過程）
雙向資料介面經常並不只是乙個輸入輸出的問題，經常還有乙個各部分互動的問題。我把資料push給你，然後你告訴我，資料有問題，不可接受，push乙個錯誤狀態給我，然後我就修正，再次提交資料。這樣的類似過程，在一些複雜介面中經常有，也是乙個雙向介面的設計難點。
介面應該被封裝。也就是說，對外來說，乙個模組或者乙個部分，只是乙個黑盒，黑盒裡任何內部處理都給遮蓋起來。而對內來說，一切的資料交換都要通過這個輸入輸出來完成，不應該有特殊。乙個好的封裝的系統，不應該在內部使用全域性的外部的東西。
介面輸入輸出，這個口應該開的盡可能的小，但是是在滿足需求的情況下。輸入來說，不要把不需要的東西也放近來，輸出的時候，只把必要的需要的輸出。
把介面開大可以滿足資訊輸入的要求，但為什麼不能把介面搞大些？這裡我覺得主要是考慮到乙個模組的問題。假如你在乙個軟體裡把兩個模組的介面搞的太大，為什麼不把兩個模組搞成乙個呢？假如是在兩個軟體系統中，把介面搞的過大，也就是說，乙個系統有太大的許可權，去取得另乙個系統的資料，會不會留下安全隱患呢？所以我個人覺得，適用乙個夠用就好的原則。
先硬後軟原則。一般的和硬體有關係的介面，都適用這一原則。硬體的限制，使你不得不在軟體上滿足硬體的需求。對於軟體設計師來說，軟體是我的可控部分，而硬體是不可控部分。
介面內容設計。這個部分每個介面不同，我也不多說了。
模組劃分。有的部分，可以分模組，有的不必要。劃分了模組的好處在於，可以對模組的功能有乙個明確的劃分，可以分別對每個模組進行處理，進行開發。但缺點是有模組就有介面，但考慮到乙個介面的複雜性，整合各個介面構成乙個整體的難度。這裡有乙個平衡點。
（今天先說這麼多了，還沒想到有修改的，以後再說，就當我把現在想到的，在csdn上留個備份了，呵呵。）
UI介面設計 介面設計流程
人類社會逐步向非物質社會邁進，網際網路資訊產業已經走入我們的生活。在這樣乙個非物質社會中，與軟體這些非物質產品再也不象過去那樣緊緊靠技術就能處於不敗之地。工業設計開始關注非物質產品。但是在國內依然普遍存在這樣乙個稱呼 美工 工 的意思就是沒有思想緊緊靠體力工作的人。這是乙個很愚昧的做法，愚昧在於稱呼...
介面設計文件 介面設計的五點建議！
介面是目前 前後端互動 rest 系統互動 rpc 最普遍的一種方式。乙個好的介面，應該清晰易懂，職責明確，易於維護。反之，則會造成很多困擾。特別是open api，誰做誰知道。基於這樣的前提以及自己之前踩過的坑，就成了這篇文章的由來。文件與程式設計師之間有著一種非常奇妙的關係。一句話概括就是 寫之...
關於介面設計的冪等性
由於各種不可控因素導致同乙個介面使用相同的引數被呼叫了n次，而不影響其結果。1 查詢和刪除天然冪等 2 在插入操作中，可使用部分字段建立唯一索引或組合唯一來防止髒資料的產生 3 在前端操作時，可在開啟頁面時向伺服器申請乙個token令牌，使用一次之後刪除，用來防止重複提交 4 悲觀鎖 假設每次操作都...