6

CustomButtonこのインターフェースがあるとしましょう：

@interface CustomButton : UIButton
    @property (nonatomic, assign) CGFloat minWidth;
@end

変更のたびに、もう一度minWidthレイアウトしたいと思いますCustomButton。私の知る限り、解決策は 2 つあります。

資産価値の観察

// In -initWithFrame:
[self addObserver:self forKeyPath:@"minWidth" options:0 context:nil];

// In -observeValueForKeyPath:ofObject:change:context:
[self setNeedsLayout];

minWidthのセッターのオーバーライド

// In -setMinWidth:
_minWidth = minWidth; // Side note: it's an ARC project
[self setNeedsLayout];

適切な解決策はどれですか?その理由は?

4

2 に答える 2

5

プロパティを KVO するのではなく、セッターをオーバーライドする 3 つの理由が考えられます。

1: 副作用は異なる場合があります

明示的に副作用が必要または必要でない限り、抵抗 (またはこの場合はオーバーヘッド) を最小限に抑える方法は、setter をオーバーライドすることです。KVO には、指定されたプロパティへのバインディングだけでなく、オブザーバーがバインディングの期間を通じて生きているという仮定も含まれます。また、KVO のデバッグがいかに難しいかについても説明しないでください。悪名高い「NSKVODeallocateBreakのブレークポイント」は、誰かを怖がらせるのに十分です。

2: 常識

「自分自身を観察する」ことは、理論的には良い考えですが、セッターをオーバーライドするよりも正しく理解するのが難しいです。KVO は、他のオブジェクトへのバインドにのみ実際に役立つセッターに加えて、追加の (ただし最小限の) 量のオーバーヘッドでもあります。さらに、クラスを自己完結型のユニットと見なす場合、それ自体のプロパティを監視する必要はありません。セッターは正確に存在するため、特定のクラスがそのプロパティの変更に反応することを選択したり、その変更を拒否または変更したりすることさえできます。

3：みんな怠け者

自分自身を観察することで、KVO のルールにコミットしたことになります。つまり、オブザーバーとして自分を削除することを忘れずに

-observeValueForKeyPath:ofObject:change:context:.

目の前のタスクに比べて、これはあまりにも多くの作業です。なぜあなたはそれをすべて行うことを覚えておく必要があるのでしょうか?

于 2013-03-20T22:35:44.393 に答える
0

正しい答えは実際にあなたの質問にあります：

minWidth が変更されるたびに、CustomButton を再度レイアウトします。

プログラミングには絶対的な答えはありません。そのため、プログラミングは科学であると同時に芸術でもあります。ただし、プログラミングの行為が達成または作成しようとしているものの邪魔にならないようにするために採用できる戦略がいくつかあります。プログラミング自体は目的を達成するための手段です。

したがって、コードは必要なだけ複雑にする必要がありますが、それ以上は複雑ではありません。

キーと値のペアの観察を使用でき、誰もあなたを責めることはできませんが、(質問のコンテキストで)より良いアプローチは、セッターをオーバーライドすることです。そして文字通りの形。

ズームイン レベルでは、これらの単純なブロックをより複雑な構造に組み立てることができるように、コードはできるだけ読みやすく、解析しやすくする必要があります。ズームインされた詳細コードが不必要に冗長または複雑である場合、これはプロジェクト全体に摩擦として現れます (デバッグが難しく、エラーが発生しやすくなるなど)。

于 2013-03-20T23:10:47.500 に答える