臨下班前一位做引擎的小伙伴提了個小問題， Rocksdb 實現了非常多的Env backend

這一些backend 可以讓用戶根據自己需求創建不同 公共接口backend，來實現自己的文件操作或者公共線程池操作。
Env* env = new rocksdb::HdfsEnv(FLAGS_hdfs)

問題是，為什么Rocksdb 這里又多實現了一個EnvWrapper 類，class EnvWrapper : public Env，其將Env 幾乎所有的成員函數都用默認方式overrie了一遍，有必要嗎？

因為 Env的類中除了Env* Default() 之外的函數成員很多都已經是純虛函數了，它已經可以作為一個抽象類，來用其子類初始化該Env就可以了，那實現的這個EnvWrapper 中每一個函數都掉用一次Env 基類 的對應實現完全沒有意義呀，想要實現自己的子類是不是只需要繼承一下Env 基類就可以了，為什么還需要單獨增加這兩百多行代碼？

大概看了一下 Rocksdb 內部是如何使用EnvWrapper的

可以看到有非常多的實現使用EnvWrapper，而在該類實現之前的注釋中可以很清晰得看到EnvWrapper的作用：

1. 如果是只有Env 這個基類，那用戶實現自己的bakend 的時候就需要將里面所有的純虛函數都實現一遍，這對很多用戶來說代價太高，有可能他們只想修改其中一小部分函數，但卻要將所有的純虛函數override一遍。
   比如這個NoSleepEnv 只想要實現其中的幾個自己想用的函數就可以了，不需要受C++ 面向對象語法的約束了。
   

2. Rocksdb 官方在Env 中增加了一些非常有用的純虛函數，對于用戶來說(繼承EnvWrapper 的用戶)，自己不需要修改任何代碼就可以直接使用。
   比如，開發者在Env 基類中增加了一個virtual Status DisablePageCache() = 0 函數，同時同步到EnvWrapper中，這種情況下其他繼承自EnvWrapper 統一類的用戶不需要修改自己的任何代碼，就可以直接使用在這個函數。否則，直接繼承Env 實現自己的類的話 任何Env的改動都需要用戶修改自己的代碼。

可見，Rocksdb 社區代碼細節上都是站在接口的易用性、可擴展性、可維護性來實現的。最大程度得降低用戶使用Rocksdb 過程中的維護成本，實在是需要我們多多學習。。。。。。

總結

以上是生活随笔為你收集整理的关于 Rocksdb 的 EnvWrapper 作用的小讨论的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。