File類本身并不持有文件句柄，它只是集中了一系列對文件的操作方法，如Create，Open等等。這些方法全部都是靜態的，也不進行任何的安全檢測，僅僅
是直接調用pspsdk來完成任務，如果出現錯誤，則返回負值。
File的Open等方法可以創建針對指定文件讀寫的流對象FileStream，句柄由FileStream自己創建和持有管理，File::Open只是傳達路徑信息。
可以把File看作是一個門面，集中了對文件的所有操作，并且不需要創建File對象就可以直接執行這些操作。所以說File為文件的單一操作提供了快捷簡便的方式。
除了幾個創建FileStream流的操作外，其他操作都不會長期占用句柄資源，遵循"句柄創建-執行具體操作-釋放句柄"的步驟。
如果需要頻繁的操作文件，則需要一個類來長期持有句柄，避免經常性的打開和關閉文件，故此引入FileInfo類。FileInfo執行Append等操作時，都是使用事先打開的文件句柄。
同時，FileInfo也可以創建FileStream實例，但這個時候，文件的句柄生命周期應該由FileInfo來管理，FileStream可以使用這個句柄，但不能結束其生命周期，FileStream::Close()方法僅僅使這個流處于關閉（不可讀寫）狀態，但并不實際關閉文件句柄。
這種情況下，FileInfo所創建的FileStream::Close()的行為和前面File所創建的FileStream::Close()行為有差異。因為File并不持有句柄，所以它創建了FileStream對象后，句柄應該由FileStream來管理。但FileInfo所創建的FileStream是使用的FileInfo所創建好的句柄，所以它并不對此句柄負責。
實現策略：
1.使用基于繼承的多態或基于模板的靜多態。
2.使用函數回調。把Close做成調用函數指針，通過不同的FileStream構造函數調用，來設置指針指向不同的Close函數實現。（關閉句柄或不關閉句柄）
這兩種做法的優劣性正在考證中，請提出意見。
補充：File和FileInfo的關系在dotnet中也有體現，不過他們主要是從錯誤檢測方面考慮。
最終的目的是要為客戶提供一個統一的界面，所以不能用太復雜的模板。
經過慎重考慮，我還是決定用虛函數，放棄了模板。