各ビュー クラスには、複数の init メソッド (UIView の一部として既に含まれているものと追加のメソッド) があり、それぞれが同じ要素を同じ方法でセットアップします。したがって、私は通常[self initialSetup];、これらすべての要素の設定を含むメソッドをすべて実行させます。
私が遭遇した問題は、サブクラスにも initialSetup メソッドがある場合、スーパークラスの initialSetup メソッドをオーバーライドするため、スーパークラスが引き続き機能するには、メソッドを public にする必要があることです。メソッドはinit以外から呼び出されるべきではないため、これは組織に問題を引き起こします。したがって、公開する理由はありません。
完全な修正方法がない問題に遭遇しました。理想的には、通常の意味でサブクラス化できないメソッドであり、その正確なタイプのクラスのインスタンスにのみアクセスできます。
これがリスクである場合、通常はクラス名を setup メソッドに組み込むようです。したがって、代わりに次のinitialSetupようなものがありますmyViewSubclassInitialSetup。
メソッドの先頭に次のようなものを追加することもできます。
NSAssert([self isMemberOfClass:[ThisClass class]],
@"IniitalSetup called by sub- or superclass")
その後、サブクラスまたはスーパークラスが init メソッドを呼び出すと、デバッグ ビルドで例外が発生します。これにより、問題を非常に迅速に見つけることができるブレークポイントとスタック トレースの場所が得られます。
リリース ビルドにコードを追加することはありません。
の名前initialSetupを次のように変更しますinitialSetupClassName- サブクラスは、誤って同じパターンを使用したとしても、異なるクラス名を持っていたため、同じ名前を使用しません。
呼び出されたくないプライベート メソッドに "_" プレフィックスを使用することもできますが、サブクラスがそれを行う場合もあります。
残念ながらObjective C、「クリーンな」方法でそれを実現する方法は提供されていません。理想的なソリューションは、保護されたメソッドです。しかし、それは不可能ですObjective C
Apple がこの問題を抱えていたのは、UIGestureRecognizer. 誰かに呼び出されたくないメソッドがいくつかありましたが、サブクラスによって上書きする必要がありました。彼らがこれに対処するために選択した方法は、これらの「保護された」メソッドを使用UIGestureRecognizerSubclass.hして元のカテゴリを含む別のヘッダー ファイル ( ) を作成することでした。UIGestureRecognizer追加のヘッダーは、サブクラスによってのみインポートされます (つまり、サブクラス化の目的で)。詳細については、 UIGestureRecognizer クラス リファレンスを参照してください。
もちろん、追加のヘッダー ファイルの悪用を防止するものではありませんが、少なくとも意図が明確に示され、コードの構造が適切に保たれます。また、クラスを使用するだけの場合は、追加のメソッドのオートコンプリートに「悩まされる」ことはありません。
個人的には、誰も直接呼び出さないことが非常に重要な場合にのみ、追加のヘッダーを使用します。ほとんどの場合、パブリック メソッドを使用して、それが何を意図しているかをメモしても問題ないと思います。iOS フレームワークにも、これらのケースが多数あります。Fe の多くのUIViewControllerメソッドviewDidLoadなど