Questions tagged «properties»

在C＃中，以下代码有效 interface I{ int property{get;set;} } 这对我来说毫无意义。这似乎打破了接口最重要的原则之一：缺少状态（换句话说，没有字段）。该属性是否不会创建隐式私有字段？这对接口真的不好吗？

47 c#  interfaces  properties 

我有一堂课有两个readonly int领域。它们作为属性公开： public class Thing { private readonly int _foo, _bar; /// <summary> I AM IMMUTABLE. </summary> public Thing(int foo, int bar) { _foo = foo; _bar = bar; } public int Foo { get { return _foo; } set { } } public int Bar { get { return …

25 c#  object-oriented  immutability  properties 

例如，一个类似的类： class Dog { } //never mind that there's nothing in it... 然后是类似的属性： Dog Dog { get; set; } 有人告诉我，如果我不能为它想出一个更富想象力的名称，那么我必须使用： Dog DogObject { get; set; } 对如何更好地命名这些有任何想法吗？

25 c#  naming  properties 

想象一下一个具有大量服务器的系统。它们每个都有许多设置： 一些特定于服务器的 一些特定于该地区的 他们之间有些共同点 也许您可以进行一些自定义分组，例如这组服务器仅用于读取 等等 我想到的当前实践是具有压倒性能力的简单属性结构。 让我们以Google服务器为例。其中每个都有一个要加载的设置列表。 例如，伦敦服务器可能具有： rootsettings.properties，europesettings.properties，londonsettings.properties，searchengine.properties，等。 每个文件都包含一组属性，并且加载顺序使您可以覆盖属性，您可以走得更远。 举例来说：rootsettings.properties可有accessible=false作为默认，但重写在searchengine.properties与accessible=true 我在使用此结构时遇到的问题是，很容易失控。它根本不是结构化的，这意味着您可以在任何级别定义任何属性，并且许多项目可能会过时。 此外，随着网络的增长，更改中间级别变得不可能了，因为您现在影响了非常多的服务器。 最后但并非最不重要的一点是，每个单独的实例可能需要1个特殊属性，这意味着您的树最终还是为每个服务器配置了一个配置，这使其不是最佳解决方案。 如果您对更好的配置管理体系结构有任何建议/想法，将不胜感激。

15 configuration  configuration-management  properties 

我有一个C＃类，它表示Web内容管理系统中的内容类型。 我们有一个字段，允许Web内容编辑器输入HTML模板以显示对象的显示方式。它基本上使用把手语法将对象属性值替换为HTML字符串： <h1>{{Title}}</h1><p>{{Message}}</p> 从类设计的角度来看，我应该将格式化的HTML字符串（带有替换）作为属性或方法公开吗？ 作为属性的示例： public class Example { private string _template; public string Title { get; set; } public string Message { get; set; } public string Html { get { return this.ToHtml(); } protected set { } } public Example(Content content) { this.Title = content.GetValue("title") as string; this.Message …

13 c#  design-patterns  class-design  methods  properties 

我在有关.NET属性的设计问题。 interface IX { Guid Id { get; } bool IsInvalidated { get; } void Invalidate(); } 问题： 此接口具有两个只读属性，Id和IsInvalidated。但是，它们本身是只读的事实本身并不能保证它们的值将保持不变。 可以说，我的意图是要清楚地表明…… Id 表示一个常量值（因此可以安全地缓存），而 IsInvalidated可能会在IX对象的生存期内更改其值（因此不应缓存）。 我如何修改interface IX以使该合同足够明确？ 我自己尝试的三种解决方案： 该界面已经过精心设计。调用方法的存在Invalidate()使程序员可以推断出类似名称的属性的值IsInvalidated可能会受到它的影响。 仅在方法和属性的命名类似的情况下，此参数才成立。 通过事件增强此接口IsInvalidatedChanged： bool IsInvalidated { get; } event EventHandler IsInvalidatedChanged; …Changed事件的存在IsInvalidated表明该属性可能会更改其值，而事件的类似事件的缺失Id则表明该属性不会更改其值。 我喜欢这种解决方案，但其中很多其他的东西可能根本就不会使用。 IsInvalidated用以下方法替换属性IsInvalidated()： bool IsInvalidated(); 这可能太微妙了。可以暗示每次都会重新计算一个值-如果它是一个常数，则不需要。MSDN主题“在属性和方法之间选择”对此有这样的说明： 在以下情况下，请使用方法而不是属性。[…]每次调用操作都会返回不同的结果，即使参数没有更改。 我希望得到什么样的答案？ 我对解决该问题的完全不同的解决方案最感兴趣，并给出了它们如何击败我的上述尝试的解释。 如果我的尝试在逻辑上有缺陷或具有尚未提及的重大缺点，以致仅剩一种解决方案（或没有解决方案），我想听听我哪里做错了。 如果缺陷很小，并且在考虑了多个解决方案后仍然存在，请发表评论。 至少，我希望获得一些反馈，以了解哪种是您首选的解决方案，以及出于何种原因。

12 c#  design  .net  properties 

我来自C ++背景，在目前的工作中全力以赴使用C＃，并且我刚刚读了很多问答，内容涉及公共领域和属性之间的区别以及此变化和体现的所有来回变化。基本问题（例如此SO帖子和所有相关的链接问题）。所有这些问题都是根据实际存在的差异解决的，这些差异应理所当然地认为存在财产制度，但是我认为最好从所有语言的设计者首先决定支持财产的角度来解决这个问题。地方正在思考（在此处查看 Wikipedia文章中的列表））。OOP是如何从C ++ / Java扩展到Wikipedia文章有趣地标识为方法和成员数据之间的中间地带的： “也就是说，属性位于类的成员代码（方法）和成员数据（实例变量）之间，并且属性提供比公共字段更高的封装级别。” MSDN进一步增加了背景： “尽管从技术上讲，属性在本质上与方法非常相似，但是它们的使用场景却大不相同。应将它们视为智能字段。它们具有字段的调用语法和方法的灵活性。” 我想知道这种中间封装水平对于一般的编程证明是有用的。我假设在表达OOP范式的编程语言的第一个化身中没有这个概念。

12 object-oriented  programming-languages  properties 

查看Windows上的某些相机元数据File Properties（还有其他一些内容），两个分别Properties称为Focal length和35mm焦距。 我正在开发将利用这两个功能的软件Properties。到目前为止，我已经为第一个创建了一个Property名称FocalLength，但是似乎无法为另一个找到合适的名称。 我已经考虑过_35MmFocalLength或ThirtyFiveMmFocalLength，但是我认为可能会有更好的建议。 有任何想法吗？

10 c#  naming-standards  properties 

JavaFX提供了一堆新的Property对象，例如，javafx.beans.property.DoubleProperty这些对象使您可以定义可以自动观察和同步的字段。 在许多JFX示例中，MVC模型类具有许多这些Property字段，这些字段随后可以自动绑定到视图。 但是，这似乎鼓励我们将JFX属性放到我们的Domain对象中（如果您假设Model类将成为一个领域对象），这让我感到担忧是关注点分离不佳（即将GUI代码放到Domain中） ）。 有没有人看到这个问题在“现实生活”中得到解决，如果是的话，它是如何做到的？

10 properties  javafx  domain-objects 

C＃的一般指导原则是始终在公共领域使用属性。这很有意义-通过公开一个字段，您将公开许多实现细节。通过一个属性，您可以封装该详细信息，从而使其在使用代码中不会被隐藏，并且实现更改与接口更改脱钩。 但是，我想知道在处理readonly关键字时有时是否存在此规则的有效例外。通过将此关键字应用于公共领域，可以额外保证：不变性。这不仅是实现细节，不变性是用户可能感兴趣的东西。使用readonly字段使其成为公共合同的一部分，并且在将来的更改或继承中也不会破坏，而不必修改公共接口。那是财产所不能提供的。 那么，readonly在某些情况下，确保不变性是在属性上选择字段的合法理由吗？ （为澄清起见，我当然不是说您应该总是仅因为该字段恰好是不可变的而做出此选择，只有当该字段作为类设计的一部分是有意义的并且打算将不可变性包括在其合同中时才使用。我最感兴趣的答案是侧重于此是否合理，而不是在某些情况下不合理（例如，当您需要将该成员放在interface或希望进行延迟加载时）。

10 c#  immutability  properties 

在不到两年前，阅读了Robert McNally谦虚的文章“代码指令：Objective-C编码的最佳实践”之后，我采用了对我的Objective-C类的几乎每个数据成员使用属性的做法（ （截至2012年5月的第三条诫命）。McNally列出了这样做的原因（我的重点）： 属性强制执行访问限制（例如只读） 属性强制执行内存管理策略（强，弱） 属性提供了透明实现自定义setter和getter的机会。 具有自定义setter或getter的属性可用于强制执行线程安全策略。 使用单一方法访问实例变量可提高代码的可读性。 我将大多数属性都归为私有类别，因此编号1和4通常不是我遇到的问题。参数3和5更加“柔和”，并且使用正确的工具和其他一致性，它们可能会成为问题。最后，对我而言，这些论点中最具影响力的是数字2，内存管理。从那时起，我一直在这样做。 @property (nonatomic, strong) id object; // Properties became my friends. 在我的最后几个项目中，我转而使用ARC，这使我怀疑为几乎所有内容创建属性仍然是个好主意还是有点多余。ARC为我负责内存管理Objective-C对象的管理，strong如果您声明ivars ，则对于大多数成员而言，它可以正常工作。无论如何，在ARC之前和之后，您都必须手动管理C类型，并且这些weak属性大部分是公共属性。 当然，对于需要从类外部访问的任何内容，我仍然使用属性，但是这些属性仅是少数几个属性，而大多数数据成员在实现标头下被列为ivars。 @implementation GTWeekViewController { UILongPressGestureRecognizer *_pressRecognizer; GTPagingGestureRecognizer *_pagingRecognizer; UITapGestureRecognizer *_tapRecognizer; } 作为一个实验，我更加严格地执行了此操作，并且从所有属性移开属性都有一些不错的积极副作用。 数据成员代码要求（@property/ @synthesize）缩小为ivar声明。 我的大部分self.something参考资料都整理到_something。 可以轻松地区分哪些数据成员是私有的（无效）和哪些数据成员是公共的（属性）。 最后，“感觉”起来更像是苹果打算将其用于房地产的目的，但这是主观的猜测。 关于一个问题：我正在慢慢地向黑暗面发展，使用越来越少的属性来支持实现错误。您能否为我提供一些理由，说明为什么我应该坚持对所有内容都使用属性，或者证实我当前的思路，为什么我应该仅在需要的地方使用更多的ivars和更少的属性？双方最有说服力的答案都会得到我的认可。 编辑：麦克纳利（McNally）在推特上说：“我认为坚持使用房地产的主要理由是：一种做所有事情的方法，那就是做所有事情（包括KVC / KVO）。”

9 programming-practices  objective-c  properties