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

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

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

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

大概看了一下 Rocksdb 內(nèi)部是如何使用EnvWrapper的

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

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

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

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

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。