組織の目標Cクラス

前の記事で、プロジェクト構造のトピックに触れました。 私の意見では、これは美しいコードが始まる最初のステップです。

2番目のステップは、クラス自体のファイルを適切に編成することです。



一部の人にとって、Obj Cに関する記事は古風なように見えるかもしれませんが、これまでのところ、Swiftへの遍在的な移行を計画していません。 それは、新しいプロジェクトでのスムーズな代替です。 維持する必要がある大きなObjective-Cコードベースがまだあります。

また、Swiftは大規模プロジェクトで十分な経験を積んでいません。



反例として、 WYPopoverControllerを検討することをお勧めします。

彼が炉からではなく私たちのところに来たと想像してください。しかし、これは暴力的な若者の時代に書かれた私たち自身のクラスです。



ヘッダーファイルには279行、実装ファイルには2948行があります。

こんにちは⌘F、私は見逃しませんでした。



このような巨大なファイルをサポートすることは困難です。

すべての.mファイルを最大100行にしようとしています。 最大150。

これにより、マップを意識することなく、適切なロジックをすばやく見つけることができます。

ヘッダーファイルWYPopoverController.h

SDKからライブラリを接続すると、プロトコルとクラスが宣言されます。

@protocol WYPopoverControllerDelegate; @class WYPopoverTheme;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これは、WYPopoverThemeクラスのヘッダーを追加しない優れたソリューションです。

WYPopoverControllerを使用するすべてのクラスがテーマを変更する必要があるわけではありません。



ただし、WYPopoverThemeクラス自体は同じファイルで宣言されています。



これに関しては、簡単なルールがあります。

1つの.hファイル-1つ

 @interface
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

1つの.mファイル-1つ

 @implementation
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

インターフェイスの前の行「//// ...」に注意してください。

彼女は何のためですか？ 明らかに、1つのインターフェイスが終了し、別のインターフェイスが開始する場所を混同しないでください。



プロパティやメソッドを間違った場所に追加するのはとても簡単です。



各プログラマーは、ファイルが大きくなりすぎて理解しにくくなったと感じることがあります。 この病気の症状には、メソッドのドロップダウンリストの頻繁な使用またはファイル検索（⌘F）が含まれます。

別の症状は、＃pragmaマークを挿入したいという欲求です。



私はすでに病気でした、あなたのための治療法です。



#pragma markまたは "//// ..."の形式の行を使用しないでください。これは何も変更しません。最初にラベルを検索するメソッドの代わりにのみ。



最初に行うことは、クラスを個別のファイルに配置することです。 次に@class



必要なものを@class



宣言します。

#import



を最小化して、ヘッダーが変更されるたびにグローバルに再コンパイルされないようにします。

定数

 #define WY_POPOVER_DEFAULT_ANIMATION_DURATION .25f #define WY_POPOVER_MIN_SIZE
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

プライベートヘッダーファイルで削除する必要がある定義。 これらはデフォルト値です。

それらを知りたい場合は、実装に入ります。



さらに、定数はconstを使用してこのように定義する必要がありますconst CGFloat kAbc = 0.25;



。

定数を宣言する必要がある場合： FOUNDATION_EXPORT const CGFloat kAbc;







NS_OPTIONSを使用して同意します。

コントローラーを呼び出すには、このタイプを知る必要があります。 そして、コントローラーはこの知識を提供する必要があります。 それらを別のヘッダーに入れる価値があるかもしれません。 まあ、大丈夫、これはちょっとした選択です。

 @interface WYPopoverController"
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

UIAppearanceContainerをサポートしています。 1つの場所で簡単に構成できます。 プラス記号。 詳細はこちら 。

プロパティ

プロパティのリストがコンパイルされる理由を、どのような原則で理解していないのですか。 実装時にヘッダーに追加されたようです。



トピックにデリゲートをもたらし、残りの設定をカテゴリまたはアルファベット順にグループ化しました（haveAに設定されています）。

 @property (nonatomic, assign) BOOL dismissOnPassthroughViewTap; @property (nonatomic, assign) BOOL dismissOnTap; @property (nonatomic, assign) BOOL implicitAnimationsDisabled; @property (nonatomic, assign) BOOL wantsDefaultContentAppearance; @property (nonatomic, assign) CGSize popoverContentSize; @property (nonatomic, assign) float animationDuration; @property (nonatomic, assign) UIEdgeInsets popoverLayoutMargins; @property (nonatomic, copy) NSArray *passthroughViews; @property (nonatomic, readonly, getter=isPopoverVisible) BOOL popoverVisible; @property (nonatomic, strong) WYPopoverTheme *theme; @property (nonatomic, strong, readonly) UIViewController *contentViewController; @property (nonatomic, weak) id <WYPopoverControllerDelegate> delegate; @property (nonatomic, copy) void (^dismissCompletionBlock)(WYPopoverController *dimissedController);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ちなみに、assignはオプションで次のように記述できます。

 @property (nonatomic) BOOL dismissOnPassthroughViewTap;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

popoverVisibleのgetterがisPopoverVisibleとして定義されているのは良いことです。このプロパティはオブジェクトの状態に関する質問に答えるので、次で始まります：

 @property (nonatomic, readonly, getter=isPopoverVisible) BOOL popoverVisible;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ただし、dismissOnTapなどでは、カスタムgetterを作成する必要もあります。

 @property (nonatomic, assign) BOOL dismissOnTap;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

このプロパティは、特定のイベント中にオブジェクトに何が起こるかという質問に答えます。

具体的には、tapuで何をする必要があるか。

このようなオプションの場合、接頭辞にgetterを定義します（英語を間違って使用した場合は修正します）。

 @property (nonatomic, getter=willDismissOnTap) BOOL dismissOnTap;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

追加の責任

 + (void)setDefaultTheme:(WYPopoverTheme *)theme; + (WYPopoverTheme *)defaultTheme;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

テーマオブジェクトがある場合、それ自体がデフォルト状態を制御する必要があります。

クラスに責任を追加するのはなぜですか？

WYPopoverThemeへの転送。



しかし、クラスメソッドはメソッドのリストの一番上になければならないことに同意します。

初期化

 - (id)initWithContentViewController:(UIViewController *)viewController;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

提案されたメソッドは[self init]を呼び出します。つまり、使用する前にオブジェクトが必要なデータをすべて初期化することを確認できます。

しかし、これについて調べるには、ソースを調べる必要がありました。



ただし、単にinitを呼び出す場合、contentViewControllerを設定する方法はありません。 なぜなら 彼は読み取り専用です。

したがって、使用する必要がないメソッドとしてintをマークし、目的の初期化メソッドとしてinitWithContentViewControllerをマークする必要があります。



それ以外の場合は、alloc initを作成することで、長い間馬鹿なことができます。



そのような方法があります。



NS_DESIGNATED_INITIALIZERを使用して、目的の初期化方法をクライアントに示します。

この方法でいくつかのメソッドをマークできます。



スーパークラスメソッドをマークすることもできます。

そのように

 - (id)init NS_DESIGNATED_INITIALIZER;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

次に、間違った初期化子を呼び出すと、Xcodeにコーニングが表示されます（エラーがあります）。



メソッドはidを返します。

instancetypeを使用することをお勧めします 。 その後、メソッドは常に、呼び出し元のクラスのインスタンスを返します。 たとえ彼から引き継いだとしても。

ヘルパーメソッド

 // theme - (void)beginThemeUpdates; (void)endThemeUpdates;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

コメントに気づきましたか？ これも症状です-ヘッダーファイルが大きすぎます。

この問題をさらに解決します。



セクション「//クラシックビューメソッドからポップオーバーを表示」

これは本当の病気です。 ファイルが大きくなりすぎています-ヘッダーを共有する必要があります。



これを行うには、カテゴリを使用します。

Appleの.hファイル（UIView.hなど）から判断すると、彼らも同様です。



このセクションのメソッドを使用して、「//バーボタンアイテムメソッドからポップオーバーを表示」し、PresentationFromViewカテゴリを作成します。



⌘N-> iOS-> Source-> Objective-C File





これらのメソッドの実装をファイルWYPopoverController + PresentationFromView.mに転送します。

WYPopoverControllerインターフェイスの後にWYPopoverController + PresentationFromView.hからWYPopoverController.hにインターフェイスをコピーし、それにメソッド宣言を転送します。



ファイルWYPopoverController + PresentationFromView.hが削除されます。



一般に、.hファイルが不要なカテゴリには特別なテンプレートを用意する方が簡単です。



次のようになります。

 @interface WYPopoverController (PresentationFromView) - (void)presentPopoverFromRect:(CGRect)rect inView:(UIView *)view permittedArrowDirections:(WYPopoverArrowDirection)arrowDirections animated:(BOOL)animated; ……………………………………………………………………… @end
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これらのメソッドはパブリックなので、宣言はWYPopoverController.hにあります。

カプセル化に違反するパンツを見せず、拡張機能（拡張機能）Privateでprivateメソッドを宣言します。 カテゴリがある場所に作成されます。



すべての.mファイルでインポートする必要があります。



#import "WYPopoverController_Private.h"



その中に、さまざまなカテゴリの作業に必要なファイルをインポートする必要があります。

1つのカテゴリにのみ必要なファイルは、特定のカテゴリの.mファイルにインポートする必要があります。



そこで、すべてのプライベートプロパティとメソッドを宣言します。



相続人が使用するヘッダーファイルが必要な場合は、Protectedと呼ばれます。



1つの論理グループに帰することができるすべてのメソッドで同じことを行います。



.mファイルが大きくなりすぎている場合は、別のカテゴリを強調表示します。

ただし、無理をしないでください。4〜5個のカテゴリが最大です。それ以外の場合は、混乱し始める可能性があります。



さらに必要な場合は、クラスにあまりにも多くの責任を与えようとしている可能性があります（ 神オブジェクト ）。 この場合、これらの責任を別のクラスに取ります。 このようなスーパークラスを本当に作成する必要がある場合は、ファサードを作成します。



もちろん、実装前にクラスを設計することをお勧めしますが、常に機能するとは限りません。

カテゴリは機能を完全に分離するのに役立ちます。 その後、苦労せずに別のクラスに実行できます。



クラスをいくつかの個別のクラスに分割する場合、2つのクラス間の多数の呼び出しを避けてください。

そうしないと、コードの接続性が高くなり、分離の意味がなくなります。 オブジェクトは、1つのメソッドが呼び出されるブラックボックスであり、データを処理した後、反対方向に1つのメソッドを呼び出します。 スイスのナイフはありません。



カテゴリは、プロトコルメソッドを配置するのに適した場所です。

これを行います：

 @interface WYPopoverController (TableView) <UITableViewDataSource, UITableViewDelegate>
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

または、IBActionをUserActionsカテゴリに入れます。

少し前まで、Xcodeは実装ファイルでIBActionを定義することを学びました。

ただし、ヘッダーでそれらを宣言する必要があります。そうすれば、実装がどこにあるかを簡単に理解できます。



1つのカテゴリでパブリックメソッドとプライベートメソッドを定義する必要がある場合があります。



次に、WYPopoverController.hにTableViewカテゴリを追加します。

WYPopoverController_Private.hのカテゴリはTableView_Privateであり、実装ファイルはWYPopoverController + TableView.mになります。



プロジェクトのクラスは次のようになります。





前の記事へのコメントで、 greenkaktusは「#pragma、#warning、// FIXME」の使用方法を説明するよう提案しました。



特定の場所で渦を無効にする必要がある場合にのみ#pragmaを使用します。

これが唯一の真の方法であると確信している場合にのみ、私はそれを非常に慎重に使用します。

#pragma markは使用しません。 私はプログラマーを定規で叩きました。



#warningは使用しません。エラーとして扱われます。 いくつかの詳細は前回の記事にあります。



将来の手がかりとして「// TODO」を使用します。 たとえば、負荷の増加に伴う最適化が必要になる可能性のあるボトルネックが見られる場合。

"// FIXME"修正が必要な場所で使用しますが、少し後です。



このコードの品質についてはまだ多くのコメントがありますが、このトピックは別の記事に値します。



次の記事では、APIを操作するために使用するクラスのデバイスについて説明する予定です。

できるだけ柔軟で自動化された設計を試みました。

そのため、apiメソッドへの新しい呼び出しの追加と応答の解析は、数行で実行できます。



提案やコメントは大歓迎です。

最後まで読んでくれてありがとう。