由於專案需要,我寫的服務程序要同別的程序進行通訊,目前採用的是本地socket方式。舊工程中採用介面的是直接暴露通訊格式，由服務使用者自己寫呼叫函式，封裝資料進行通訊，這會有以下幾點問題：
1、使用煩瑣，每個不同的程序都需要寫自己通訊函式：建立socket，鏈結，寫入，讀出，關閉等一系列重複的操作。
2、通訊格式改動不便。由於服務公升級或者別的原因通訊格式會產生變動，而這種介面方式一旦變動就需要把所有呼叫者的程式重新修改編譯。
3、公升級擴充套件不方便。也是由於上點的原因，如果我想加入新的功能，或者改變現有功能必須重新編寫呼叫者的函式。
綜上，需要開發乙個動態庫給呼叫者使用，只要我保證介面規格不變，內部實現可以隨意公升級，額外代價只是覆蓋掉舊的動態庫，而且減少了呼叫者重複工作，增加了開發效率。
在設計和實現該介面過程中，遇到如下問題：
1、本地socket檔案位置問題，舊的方案是把socket檔名作為常量字串直接寫在**中，但是服務端的socket檔案是可配置的，如果被使用者配置為另外的檔案，就不能成功通訊，所以必須要採用一種更好的方案。後來和老趙討論了這個問題，我說要不要直接讀服務的socket檔案，反正這個檔案的位置不會變動，可以直接hardcoding到**中。老趙說這樣就破壞了結構性，服務的配置檔案不是客戶端需要關心的東西。最後提出了乙個方案，客戶端可以通過自己的配置檔案來得到服務端的socket檔案位置，然後作為引數傳給通訊庫，如果引數有效，那麼就使用，如果無效就使用通訊庫的**中寫入乙個預設的socket。這樣算是比較好的解決了問題，而又不會使得呼叫者改動太多。
2、內部還是外部狀態的問題。當前服務端採用的方案是每進行一次通訊就需要開啟和關閉一次socket，所以我打算在通訊庫裡面也進行同樣的操作，其通訊socket由初始化引數決定，作為乙個static變數儲存在通訊庫中。但是在web處理這種小資料，大併發量的任務中可能會造成io開銷過大。所以通訊格式以後可能會改動為在規定時間內維持socket通訊，或者一方顯式的提出關閉通訊的請求才會結束這次通訊。目前有兩種更好的方案，1是使用外部變數儲存socket資訊，由初始化函式去初始化之，這樣不同的外部變數可以儲存不同的socket通訊，之間互不干擾。所以我以後公升級了通訊方式也不會對程式產生影響了。2是庫內部內建乙個池，池的容量，預設量，最小量可以由初始化函式決定，池內儲存了很多待用的socket，我使用互斥的訪問它們就可以了。第1種方案效能呼叫者擁有更大自主性和優化空間，但是使用起來也麻煩，需要自己保管外部狀態變數的空間以及狀態。第二種方案包裝的更加完整，呼叫者使用起來很方便，完全不用關心通訊狀態，但是由於使用了互斥，在高頻訪問下造成效能下降。到底使用哪個方案還得要看實際環境下哪種更有優勢。
介面的問題很大一部分就是乙個封裝的問題，封裝的太多，使用者感覺不夠靈活，不能微調；封裝太少了，用起來又繁瑣，容易出錯。同樣需要在實際環境下去觀察，分析，總結。
所謂計算機工程師和計算機科學家不同，他們不鑽到理論中，去發明什麼新的東西，而是利用已有的成熟的資源，去根據工程引數的不同而使用和改造現有方法。以工程化（可測量，可計算，可推斷，可重現）的方法在時間空間人力財務各個方面使用最優的手段去解決實際問題，這才是工程師存在的本質。我想自己正向著工程師邁進，可原本的願望卻是後者呢（你原本到底有沒有願望 --!）．．．
關於介面的思考
1 介面的意義 以前一直在思考的是介面的意義是什麼，我們定義乙個類，如果繼承了介面，就需要實現介面的全部方法和屬性，欄位等，那麼為什麼要繼承介面，直接定義我們想要的類就好了，後來隨著接觸的增多，再加上網上搜尋的一些資料，漸漸體會到介面的誕生是乙個很偉大的發明 1 介面可以定義規範，指的是我們在介面中...
關於介面的一些思考
下面示例是模擬遊戲 憤怒的小鳥 的實現。叫的方式的介面 public inte ce shouttype 嗷嗷叫 public class aoshout implements shouttype 喳喳叫 public class zhashout implements shouttype 鳥的抽象...
關於遊戲互動介面設計的幾點思考
介面資料流 玩家所體驗的遊戲世界其實是在他們的腦海中的，而玩家融入進遊戲所通過的介面，就是互動介面。互動介面的設計目標就是讓玩家 感到 他能夠自如地控制自己的體驗。上圖是乙個簡單的對映圖，我修改了一下原來的圖，覺得現在這樣更容易理解。一共是四種互動，其中只有一種互動是連線玩家的，也即玩家操作物理輸入...