golang反模式中的基本API？

-2

糾正我，如果我錯了，但對於我的unistanding API是允許我通過接口修改和請求數據，這是我想要在golang中做的事情。比如我有一個用戶界面：golang反模式中的基本API？

interface IUser { 
    GetId() int 
    GetName() string 
    GetSignupDate() time 
    GetPermissions() []IPermission 
    Delete() 
}

這已經在我看來就像活動記錄，如果我想創建一個新的用戶提供一個新的ID，我將不得不使用新的自走不支持靜態函數據我所知，這意味着我還需要一個提交功能在我的界面，這使得它更糟，我在這裏做錯了什麼？

來源

2015-06-27 Vic

你在這裏不是很清楚你將如何看待API。也就是說，只要習慣了Go如何執行API並使用它。看看包含的IO模塊如何與Reader，Writer以及各種緩衝區一起工作。不要試圖複製Java或C＃或任何其他模式，因爲它會讓其他Go程序員感到錯誤。 –

關於向接口添加函數的另一個評論。考慮添加另一個界面。如果你需要將一個對象保存到數據庫中，你可能會有第二個接口這樣做，然後在你的BasicUser結構上實現它。 –

在Go中，接口是行爲的。也就是說，他們描述了什麼確實多於是。你的例子看起來像你正在嘗試在Go中編寫C＃，並在接口類前面大量使用I。但是，僅由一種類型實現的接口有點浪費時間。

相反，考慮：

interface Deleteable { // You'd probably be tempted to call this IDeleteable 
         // Effective go suggests Deleter, but the grammar 
         // sounds weird 
    Delete() err 
}

現在你可以創建執行批處理功能刪除：

func BatchDelete(victims []Deleteable) { 
    // Do some cool things for batching, connect to db, start a transaction 
    for _, victim := range(victims) { 
     victim.Delete() // Or arrange for this function to be called somehow. 
    } 
}

你很可能得到通過更新創建界面啓動速度更快，序列化等在和存儲您的實際用戶/權限/等在實現這些方法的具體結構。（注意在Go中，你不必說某個類型實現了一個接口，它會自動發生）。你也不必爲每個方法的單一接口（更新，可序列化），但你可以捆綁他們都到一個界面：

type DBObject interface { 
    Update() 
    Serialize() RowType 
    Delete() 
} 

type User struct { 
    Id int 
    Name string 
    // ... etc 
}

記住，你的模型可以始終用戶對象「中填寫」從API返回，即使User對象的實際表示是更加分散的，例如RDF三元組。

來源

2015-06-27 23:17:34

但是，只要我添加函數來訪問和修改數據，我會混淆一個對象和一個數據結構，這是一個反模式http://programmers.stackexchange.com/questions/119352/does-the-activerecord-pattern -follow-encourage-the-solid-design-principles 如何解決這個問題？ – Vic

@Vic：這是你的反模式關注嗎？在天空中的某個理論上，這是一個真正的問題還是問題？如果這是一個理論問題，忽略它並做一些有效的工作。忽略理論，因爲它沒用。 –

golang反模式中的基本API？

回答

相關問題