我是新來扭曲，我遇到麻煩，我應該如何組織我的代碼。客戶端連接到TCP（SSL）控制通道，然後根據通過TCP提供的加密設置，嘗試連接到UDP上的相同IP：端口以用於低延遲數據通道。如果不能，TCP控制通道將用於數據。我想寫一個可重用的客戶端，以便人們可以使用諸如dataReceived，controlMessageXReceived，sendControlMessageX，sendDataMessage等函數來覆蓋具有UDP通道是否正在使用或不被抽象到我的代碼中的類。如何組織使用扭曲的多連接客戶端？
我目前有一個可以理解TCP控制通道的協議;出於測試的目的，我已經重寫了ConnectionMade（）以發送設置消息並確認一切正常（它可以理解服務器，反之亦然），但我不知道如何將它整合到更廣泛的上下文中。
（對於好奇，這是Mumble客戶 - 這個協議規範here，我試圖更新的umaintainable（多線程）的代碼this可怕的一堆弄成現代）
考慮鏡像協議/傳輸分離已經存在於Twisted中。
Protocol對TCP沒有任何瞭解。它只知道如何處理一個字節流。它是知道TCP（或TLS，或UNIX套接字或其他）的傳輸方式。
有Protocol和運輸之間的一個顯式接口（實際上有兩種 - IProtocol讓運輸知道什麼可以做的協議對象和ITransport讓協議知道什麼可以做傳輸對象）。
創建一個對您正在使用的應用程序有意義的接口。例如，Protocol具有dataReceived，因爲「某些字節到達」是「字節流」發生的事情之一。 Mumble會發生什麼事情？例如，這些可能是「連接到服務器的用戶」或「到達您所在頻道的消息」。你的界面可能有每個這樣的方法。
現在，應用程序開發人員可以通過編寫此接口的實現（這是明確且完全定義的），然後將該實現插入到您的庫中（例如，您的庫可能提供一個connectToMumbleServer(address, mumbleApplicationObject) API）來實現自己的新穎行爲。
由於該接口是明確定義的，因此您的庫確切知道它可以對應用程序對象執行什麼操作。如果您重複這個過程的方向相反，那麼應用程序開發人員也會知道他們可以使用您的庫對笨拙的服務器執行什麼操作（例如「加入頻道」或「發送音頻數據包」）。
你可能提供基類（如Protocol）的應用程序的子類，但這是一個非常輕微的便利。如果您最近沒有，請打開twisted/internet/protocols.py並查看Protocol課程的實施情況。幾乎沒有任何東西存在，並且沒有任何東西複雜或難以複製。如果應用程序開發人員不得不從子類化object開始，並自行輸出所有的方法，那麼它們就不會成爲太大的缺點。