override getter只需要@synthesize

Gre*_*zek 7 objective-c getter-setter synthesize xcode5

我想为懒惰的实例化提供ovveride getter并保留默认的setter.

我需要@synthesize吗?

为什么?

@interface Foo()
@property (strong, nonatomic) NSObject *bar;
@end

@implementation Foo
- (NSObject *)bar
{
    if(!_bar) _bar = [[NSObject alloc] init];
    return _bar;
}
@end
Run Code Online (Sandbox Code Playgroud)

更新:我已经更改了变量和类名,因为它令人困惑.从甲板和卡到Foo和酒吧.

Rob*_*Rob 16

不,如果你明确地实现了所有的访问器方法(readwrite属性的getter和setter ,只是属性的getter readonly),你只需要显式合成(获得合成的ivar ).你已经为这个readwrite属性编写了getter ,但没有为setter 编写,所以ivar仍然会为你合成.因此,正如您的代码所代表的那样,您不需要明确@synthesize.

如果你创建了这个属性readonly,那么实现一个getter会阻止你的ivar自动合成.同样,既然如此readwrite,如果你实现了getter和setter,那就需要你合成ivar(如果你想要的话).

  • _ + 1_换句话说:如果您的代码编译,那么您就是好的.如果您需要`@ synthesize`,编译器将不允许您使用`_cards` ivar. (4认同)

bbu*_*bum 5

不要以这种方式使用延迟初始化.如果没有卡片,甲板就没用了,因此,懒惰的初始化只会在第一次调用该getter时对你进行不确定的消耗.幸运的是,简单地创建一个可变数组就没有任何成本(这也是不使用延迟初始化的原因).

同样,出售可变集合会破坏封装.甲板应该包含所有逻辑,用于确定它包含的卡组和顺序.通过出售可变集合,外部代码可以改变Deck背后的顺序.

除此之外,它甚至意味着"设置"甲板卡?走这条路线似乎推动了所有与维护甲板之外的甲板相关的逻辑,乞求问题为什么甲板只不过是一个普通的旧阵列,无论什么类使用甲板.

  • 防止"意外分配零"是一种浪费."OOops,我不小心分配了nil并丢失了所有游戏状态的收集.但是,不用担心,下次我调用getter时,我会以默认顺序返回空游戏状态或游戏状态.当然,用户永远不会注意到!"**变异的getter是糟糕的设计,懒惰的初始化*通常*不明智.** (3认同)