c# – 默认情况下为什么WPF控件不是私有的？

内容导读

互联网集市收集整理的这篇技术教程文章主要介绍了c# – 默认情况下为什么WPF控件不是私有的？，小编现在分享给大家，供广大互联网技能从业者学习和参考。文章包含1360字，纯文字阅读大概需要2分钟。

内容图文

在WPF中,写作

<TextBlock x:Name="foo"/>

将控制公开.要使其成为私有,必须明确指定FieldModifier：

<TextBlock x:Name="foo" x:FieldModifier="private"/>

我觉得这很奇怪.我不认为直接从课外访问子控件是一种很好的编码风格.例如,我会避免写作

var muc = new MyUserControl();
muc.foo.Text = "foo";

相反,我会写一个公共方法并使用它：

public void SetFooText(string text) { foo.Text = text; }

// in somewhere else
var muc = new MyUserControl();
muc.SetFooText("foo");

或写一个公共财产

public string FooText 
{ 
    get { return foo.Text; } 
    set { foo.Text = value; } 
}

// in somewhere else
var muc = new MyUserControl();
muc.FooText = "foo";

所以,我没有看到默认情况下将控件设置为public的任何优点.如果私有是默认的,就像C#中的所有东西一样,也许会更安全.

为什么公开默认？

编辑：

好吧,我搞错了.默认是内部的,正如其他人提到的那样.但是为什么它不是私人的问题仍在等待答案.

解决方法:

C#的默认值：C#的FieldModifier是NotPublic(内部)

TypeAttributes.NotPublic is the default behavior because it is infrequent that code outside the assembly that compiled the XAML needs access to a XAML-created element. WPF security architecture together with XAML compilation behavior will not declare fields that store element instances as public, unless you specifically set the x:FieldModifier to allow public access.

正如我们所看到的那样,默认情况下它们是私有的,编译XAML的程序集将无法访问XAML创建的元素.

你可以在这里找到更多信息MSDN

内容总结

以上是互联网集市为您收集整理的c# – 默认情况下为什么WPF控件不是私有的？全部内容，希望文章能够帮你解决c# – 默认情况下为什么WPF控件不是私有的？所遇到的程序开发问题。 如果觉得互联网集市技术教程内容还不错，欢迎将互联网集市网站推荐给程序员好友。

内容备注

版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 gblab@vip.qq.com 举报，一经查实，本站将立刻删除。

内容手机端