NSString 属性是复制还是只读？

发布于 2024-12-13 13:02:15 字数 450 浏览 1 评论 0原文

我看到很多讨论说我应该使用 copy 作为 NSString 属性，因为它会阻止其他人在我背后更改它。但是为什么我们不直接为其设置 readonly 属性呢？

更新

感谢您回答我的问题。但问题是，对于 NSString 属性，你总是不希望别人修改它，对吗？你可以自己修改，但绝对不能让别人修改。我想大多数时候 NSString 都会设置它的初始值（由你或其他人设置），之后只有你会修改它。那为什么不直接使用只读属性呢？

实际上我大部分时间都使用复制。但后来我意识到大多数时候我只在 init 方法中使用这些设置器。所以我认为对于这些情况我应该使用只读而不是复制。

所以让我这样问一个问题：如果你在 init 方法中只对 NSString 使用这些 setter，那么你应该使用 readonly。这是一个合理的结论吗？

原文

分享到QQ

分享到微博

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

发布评论

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

国际总奸 2024-12-20 13:02:15

如果您只在 init 方法中为 NSString 使用这些 setter，那么您应该使用 readonly。这是一个合理的结论吗？

由于您不应该在部分构造状态（init/dealloc）中使用访问器，因此您应该将其声明为 copy 和 readonly< /code>，然后在初始化程序中执行复制：

- (id)initWithName:(NSString *)inName
{
  self = [super init];
  if (0 != self) {
    name = [inName copy];
  }
  return self;
}

更详细地说，copy 和 readonly 在语义上是不同的概念。

您使用copy是因为您对大多数情况下的值感兴趣。这也是使用不可变字符串的一种保障和优化。
您使用readonly来禁止客户端更改/设置您的数据。

它们一起提供了很好的安全性，但单独使用时：

copy 仍然允许客户端通过 setter 在程序执行的任何时刻设置值。
readonly 并不意味着copy，并且保留的属性可能会在您背后更改；考虑一下当您传递一个可变变体并且客户端在调用 setter 后对其进行变异时会发生什么。

最安全的方法是使用copy和readonly。

显然，当您需要向客户端提供 setter 并且您支持该更改时，您将使用 readwrite。
保留字符串（或数组，或...）而不是复制通常是一个坏主意。不复制这些类型几乎没有什么好处，而且可能会导致微妙的错误。即使当您处理可变类型时，您通常也需要一个可变副本（编译器不会为您合成）。保留或分配这些类型几乎从来都不是您想要的。我犯的一个例外是在处理大型分配时，其中数据封装得很好（例如，我将所有权从一个地方传递到另一个地方以避免复制的重型 NSMutableData 实例）。

if you only use those setters for your NSStrings in your init method, then you should use readonly instead. Is this a reasonable conclusion?

Since you should not use accessors in partially constructed states (init/dealloc), then you should declare it as copy and readonly, then perform the copy in the initializer:

- (id)initWithName:(NSString *)inName
{
  self = [super init];
  if (0 != self) {
    name = [inName copy];
  }
  return self;
}

In more detail, copy and readonly are semantically different concepts.

You use copy because you are interested in the value in most cases. It's also a safeguard and an optimization to use immutable strings.
You use readonly to prohibit clients from mutating/setting your data.

Together, they provide a good degree of safety, but alone:

copy still allows clients to set the value at any point in the program's execution via the setter.
readonly does not imply copy, and a retained property could be changed behind your back; consider what happens when you are passed a mutable variant and the client mutates it after calling the setter.

The safest way is to use copy and readonly.

obviously, you will use readwrite when you need to provide a setter to your clients, and you support that change.
retaining a string (or array, or...) instead of copying is usually a bad idea. there is rarely a good use for you not to copy these types, and it can lead to subtle errors. even when you are dealing with a mutable type, you'll usually want a mutable copy (which the compiler will not synthesize for you). retaining or assigning these types is almost never what you want. one exception i make is when dealing with large allocations, where the data is encapsulated well (e.g. a heavy NSMutableData instance which I pass ownership from one place to another to avoid a copy).

回复收藏 0 原文

薄情伤 2024-12-20 13:02:15

如果您不希望其他人修改您的属性，那么您绝对应该将其标记为只读。当人们说使用 copy 意味着字符串不能在你背后更改时，他们的意思是，如果有人将一个字符串分配给你的属性，并且该字符串是可变的，然后他们会改变该字符串，当您稍后访问您的属性时，您将返回更改字符串。但是，如果您使用copy，那么您将获得字符串在分配给属性时的外观快照（这是人们期望发生的情况）。