为什么 FileSystemInfo 不声明 GetAccessControl 方法?

发布于 2025-01-06 19:35:16 字数 2062 浏览 2 评论 0 原文

我主要对其背后的设计决策感兴趣。

背景信息:
FileSystemInfo 是(且仅)< a href="http://msdn.microsoft.com/en-us/library/system.io.fileinfo.aspx" rel="nofollow">FileInfo 和 目录信息
这两个类都实现 GetAccessControl(),返回 文件安全目录安全 对象分别。
FileSecurityDirectorySecurity 均派生自 FileSystemSecurity - 也是唯一这样做的类。
除了构造函数之外,FileSecurityDirectorySecurity 似乎都没有声明自己的任何方法或属性。

然而,FileSystemInfo 仍然不包含 public FileSystemSecurity GetAccessControl() 方法。

问题
任何人都可以阐明为什么 FileSystemInfo 不包含此方法吗?

示例代码

public static void GrantFullControlToBuiltinUsers(this FileSystemInfo fileSystemInfo)
{
    FileSystemSecurity acFile;

    if(fileSystemInfo is DirectoryInfo)
        acFile = ((DirectoryInfo) fileSystemInfo).GetAccessControl();
    else
        acFile = ((FileInfo)fileSystemInfo).GetAccessControl();


    acFile.AddAccessRule(
        new FileSystemAccessRule(GetAccountNameBuiltinUsers(),
                                    FileSystemRights.FullControl,
                                    AccessControlType.Allow));


    if (fileSystemInfo is DirectoryInfo)
        ((DirectoryInfo)fileSystemInfo).SetAccessControl((DirectorySecurity)acFile);
    else
        ((FileInfo)fileSystemInfo).SetAccessControl((FileSecurity)acFile);
}

该代码远非美观,其中包含所有(不必要的)强制转换,我想知道为什么该库是这样设计的。

I am mainly interested in the design decision behind this.

background information:
FileSystemInfo is base class to (and only to) FileInfo and DirectoryInfo.
Both classes implement GetAccessControl(), returning a FileSecurity or DirectorySecurity object respectively.
FileSecurity and DirectorySecurity both derive from FileSystemSecurity - and again are the only classes to do so.
Neither FileSecurity nor DirectorySecurity seem to declare any methods or properties of their own - apart from constructors.

Yet still, FileSystemInfo does not contain a public FileSystemSecurity GetAccessControl() method.

Question:
Can anybody shed some light onto why FileSystemInfo does not contain this method?

example code

public static void GrantFullControlToBuiltinUsers(this FileSystemInfo fileSystemInfo)
{
    FileSystemSecurity acFile;

    if(fileSystemInfo is DirectoryInfo)
        acFile = ((DirectoryInfo) fileSystemInfo).GetAccessControl();
    else
        acFile = ((FileInfo)fileSystemInfo).GetAccessControl();


    acFile.AddAccessRule(
        new FileSystemAccessRule(GetAccountNameBuiltinUsers(),
                                    FileSystemRights.FullControl,
                                    AccessControlType.Allow));


    if (fileSystemInfo is DirectoryInfo)
        ((DirectoryInfo)fileSystemInfo).SetAccessControl((DirectorySecurity)acFile);
    else
        ((FileInfo)fileSystemInfo).SetAccessControl((FileSecurity)acFile);
}

The code is far from beautiful with all the (unnecessary) casts in it and I wondered why the library was designed in this way.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

∞梦里开花 2025-01-13 19:35:16

我的猜测是他们想让两个 GetAccessControl 方法返回正确的具体类型 - 分别是 FileSecurity 和 DirectorySecurity。如果它们继承自通用的 GetAccessControl() 方法,则它们将被迫返回 FileSystemSecurity,并且用户必须手动转换它。

这主要是一种审美选择。

My guess is that they wanted to have the two GetAccessControl methods return the proper, concrete types - FileSecurity and DirectorySecurity, respectively. If they inherited from a common GetAccessControl() method, they would be forced to return FileSystemSecurity, and the user would have to cast it manually.

It's an aesthetic choice, mostly.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文