是什么讓這段代碼變壞了

Question

在我的公司，我遇到了以下兩個代碼片段，我發現這些代碼片段一見鍾情，但本着向撰寫該代碼的工程師提供建設性反饋的精神，我試圖提出技術論據，為什么這段代碼是壞：

FileTableEntry * FilerManager::GetFileTableEntry(uint32_t i) const {
  return &(GetFileTable()[i]);
}

…
for (uint32_t i = 0; i < container_.size(); ++i) {
   *GetFileTableEntry(i) = FileTableEntry();
   // GetFileTableEntry ultimately accesses a std::vector in FileManager
}

我的主要論點是：

1. 這段代碼非常間接和誤導，它不應該使用getget來初始化（FileManager的一部分），但至少是一個setter：更直接使代碼更容易理解。
2. getter完全泄漏了FileManager的內部狀態，因此FileManager的封裝在這一點上沒有任何意義。 更糟糕的是，getter承諾適用於const對象，但是很快就會用來改變FileManager的內部狀態。 打破封裝是使重構更難的必由之路。

還有其他論據不寫這樣的代碼我會遺漏嗎？

Answer 1

反對此代碼的另一個參數是GetFileTableEntry的簽名在對象始終存在的情況下返回指針。 這需要引用，而不是指針：

FileTableEntry& FilerManager::GetFileTableEntry(uint32_t i) const {
    return GetFileTable()[i];
}

這應該解決你的第一點。 你的第二點可以通過引用const來解決：

const FileTableEntry& FilerManager::GetFileTableEntry(uint32_t i) const {
    return GetFileTable()[i];
}

這禁止調用者修改GetFileTableEntry返回的內部狀態。

注意：要使GetFileTableEntry函數有用，應該添加傳入的索引的邊界檢查以及早捕獲錯誤。