36

a のサブクラス化に関するスタック オーバーフローについていくつか質問しましたが、何UIButton人かから a をサブクラス化すべきではないとの連絡がありましたUIButton。

a をサブクラス化することの欠点はUIButton何ですか? そして、それが曖昧であることは知っていますが、 a をサブクラス化する他の代替手段は何UIButtonですか?

4

3 に答える 3

36

Cocoa フレームワークは、オブジェクト構成パターンが従来のクラス階層よりも適切であるというアプローチを採用しています。

一般に、これは、ボタンのさまざまな側面を処理するために別のオブジェクトを設定できる UIButton のプロパティがある可能性が高いことを意味します。これは、ボタンの動作を「カスタマイズ」するための推奨される方法です。

このパターンの主な理由の 1 つは、多くのライブラリ コンポーネントがボタンを作成し、サブクラスのインスタンスを作成する必要があることを認識していないことです。

edit、独自のファクトリメソッド

アプリ内の多くのボタンで同じボタン構成を使用している場合の時間の節約に関する上記のコメントに気付きました。これは、ファクトリ メソッド デザイン パターンを使用する絶好の機会です。Objective-C では、UIButton で直接利用できるように、カテゴリを使用して実装できます。

@interface UIButton ( MyCompanyFactory )
+(UIButton *) buttonWithMyCompanyStyles;
@end
@implementation UIButton
+(UIButton *) buttonWithMyCompanyStyles {
    UIButton *theButton = [UIButton buttonWithType:UIButtonTypeCustom];
    // [theButton set...
    return theButton;
}
@end
于 2012-11-02T20:01:35.123 に答える
16

これは、期待どおりに動作するために必要UIButtonないくつかの複雑さ/微妙さ/制限 (つまり、特に定義する追加のオーバーライド) があるという点で、一種の特別だからです。+buttonWithType:それは通常以上のものです-initWithFrame:(そして-initWithCoder:、XIB で使用されている場合)。IDK フレームワークの作成者が、これらの詳細が私たちのドメインに漏れることを許可した理由ですが、それは私たちが今対処しなければならないことです. 制限は、実装が事前設定されたシステム ボタン スタイルに依存 (つまり、拡張) してはならないということです。サブクラスUIButtonTypeCustomの出発点として想定する必要があります。UIButton

サブクラスの実装についてUIButton

于 2012-11-02T20:20:15.660 に答える