objective-c - iOS で独自のカスタム ライブラリを作成しますか?

Question

私はプログラミングにかなり慣れていないので、より効率的にプログラミングを始めたいと思っていました。できる限り試してみると、MVC モデルから外れていることがよくあります。

xcode objc でコーディングするときにコードを整理するためのヒントや方法はありますか? より具体的に言うと（皆さんが好きなのは知っています:)私はしたいです

1. あるプロジェクトから別のプロジェクトに持ち込むことができるライブラリまたは自己完結型のコードを作成できる
2. 自分のコードをオープンソース プロジェクトとして他のユーザーと共有する
3. 適切な構造に従わない乱雑なコードを書かないようにする

Answer 1

• 高い警告レベルを使用してください。きれいにビルドします。
• すべての静的アナライザーの問題を取り除きます。
• いくつかの単体テストを作成します。
• パブリック インターフェイスを小さく保ちます。
• ライブラリの依存関係を指定します (最小 SDK バージョンや依存ライブラリなど)。
• 複数の/サポートされている OS バージョンに対して定期的にコンパイルします。
• 静的ライブラリ ターゲットの作成と管理について学習します。別のプロジェクトでライブラリをサポートして再利用するために必要なのはこれだけです (外部リソースを画像にドラッグしない限り、面倒です)。
• グローバル状態なし (シングルトン、グローバル変数など)。
• マルチスレッド コンテキストでのサポートについては正確に記述してください (より一般的には、同時実行はクライアントの責任です)。
• 公開インターフェースを文書化します (おそらく、非公開インターフェースも…)。
• 正確で均一な誤差モデルを定義します。
• 十分なエラー検出を行うことはできません。
• 非常に高い基準を設定する -- リファレンス実装として再利用できるように構築します。
• ライブラリの粒度を早い段階で決定します。これらは非常に小さく、集中する必要があります。
• バックエンド/コア ライブラリに C または C++ の実装を使用することを検討してください (そのようなものは取り除くことができます)。
• ライブラリの objc クラスとカテゴリのプレフィックスを確立して指定してください。適切なプレフィックスも使用してください。
• 目に見える依存関係を最小限に抑えます (たとえば、#import非表示になる可能性のある大量のフレームワークを使用しないでください)。
• クライアントが を追加しなくてもコンパイルできることを確認してください#import。
• クライアントが特定の場所に物を置いたり、リソースに特定の名前が付けられたりすることに依存しないでください。
• メモリ消費量と実行コストについては、非常に控えめにしてください。
• 漏れはありません。
• ゾンビはいません。
• メインスレッドでの遅いブロッキング操作はありません。
• 十分にテストされ、しばらく安定するまで、何かを公開しないでください。バグはクライアントのコードを破壊し、プログラムを破壊し続けるとライブラリを再利用する可能性が低くなります。
• 優れた図書館を研究し、利用し、学びましょう。
• 誰か (理想的には、あなたよりも経験豊富な人) にコードのレビューを依頼してください。
• プロジェクトの適切な場所でライブラリを使用/実行してください。
• 機能を追加する前にバグを修正します。

怖がらせないでください。本当に楽しく、その過程で多くのことを学ぶことができます。

Answer 2

コードを再利用する方法はいくつかあります。

• コードを共通ディレクトリに保存し、そのディレクトリをプロジェクトに含めます。シンプルですが、バージョン管理の問題が発生する可能性があります。
• 静的な iOS ライブラリを構築する別のプロジェクトを作成してから、フレームワークを作成します。フレームワークのディレクトリ構造を構築するためのスクリプトが必要なため、セットアップがより複雑になります。しかし、他のプロジェクトで簡単に使用でき、バージョニングとデバイス/シミュレーターを組み合わせたライブラリを処理できます。
• 静的な iOS ライブラリを構築する別のプロジェクトを作成し、これをサブプロジェクトとして他のプロジェクトに含めます。フレームワークを構築する必要がなくなり、結果をより最適化できます。

これが基本の 3 つです。もちろん、これらにはさまざまなバリエーションがあり、どのように処理するかを説明します。あなたがやろうと決めたことの多くは、あなたが誰のためにこれをやろうとしているかにかかっています。たとえば、私は自分のコードのサブ プロジェクトが好きですが、他の人が利用できるようにしたいコードについては、フレームワークの方が優れていると思います。作成する作業が増えたとしても。さらに、それらを API ドキュメントのドキュメントセットでまとめて、すべてを DMG として github にアップロードし、他のユーザーがダウンロードできるようにします。