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中也有体现，不过他们主要是从错误检测方面考虑。
最终的目的是要为客户提供一个统一的界面，所以不能用太复杂的模板。
经过慎重考虑，我还是决定用虚函数，放弃了模板。