Interface Builder は Cocoa アプリの基本的な依存性注入に使用できますが、NIB ファイルでオブジェクトをインスタンス化したくない場合に備えて、Objective-C/Cocoa のより完全な依存性注入フレームワークを知っている人はいますか?
編集
明確にするために、IBは基本的なDIに使用できることを認識していますが、GroovyまたはSpringsのラインに沿って、個別の運用構成とテスト構成を含む、より完全な機能を備えたフレームワークを探しています.
Interface Builder は Cocoa アプリの基本的な依存性注入に使用できますが、NIB ファイルでオブジェクトをインスタンス化したくない場合に備えて、Objective-C/Cocoa のより完全な依存性注入フレームワークを知っている人はいますか?
編集
明確にするために、IBは基本的なDIに使用できることを認識していますが、GroovyまたはSpringsのラインに沿って、個別の運用構成とテスト構成を含む、より完全な機能を備えたフレームワークを探しています.
AtomicObjectによる異議。ギースをイメージした造形です。
私は手足を出して、これについて話します。一番上の回答で説明されている依存性注入は、それを使用しようとしている人が抱えている中心的な問題に対処していません。コンポーネント A がコンポーネント B を直接インスタンス化または参照しない開発手段が必要です。コンポーネント A はプロトコルによってコンポーネント B にバインドされ、コンポーネント A からはまったく参照されません。これにより、コンポーネント B をいつでも置き換えることができます。コンポーネントAに触れています。私は反対票を投じましたが、あなたに同意する人が何人かいるように見えるので、あなたの参照を調査します。私は議論しようとしているのではなく、ただ学びたいだけです。「いいえ、それをする必要はありません」というアプローチについてもっと理解したいと思います。
Objective C、Ruby、Lisp などの遅延バインディング言語では必要ないことがわかると思います。ジェイミスが針を作ろうとしたときに過度に複雑な道を進んでいたことを明らかにしたように、Ruby- Net::SSH の DI フレームワークが再訪されました。
以下は、Objective C で同様のことを行うためのサンプル コードを提供するリンクです。カテゴリを使用すると、基本的に実行時に任意のクラスの動作を変更できます。Mac 開発者向けのヒント – Objective-C: カテゴリおよびカテゴリに関するCocoa API ドキュメント を参照してください。TheThingThatDoesX を直接インスタンス化することができ、他の何かがその動作に変更/フックする必要がある場合は、カテゴリを使用できるため、基本的に、構成可能な「x を実行するもの」を要求するための中心的な場所は必要ありません。
台風
ほぼ 1 年前に、https ://github.com/typhoon-framework/Typhoon をリリースしました。
Typhoon の Web サイトには、主要な機能が一覧表示されています。簡単な要約:
非侵襲的。マクロや XML は必要ありません。強力な Objective-C ランタイム アプローチを使用します。
同じ基本クラスまたはプロトコルの複数の構成を簡単に作成できます。
マジック ストリングなし - IDE リファクタリング、コード補完、およびコンパイル時のチェックをサポートします。
ビュー コントローラーのインジェクションとストーリーボードの統合をサポートします。
イニシャライザとプロパティ インジェクションの両方に加えて、ライフサイクル管理をサポートします。
強力なメモリ管理機能。シングルトンのメモリ オーバーヘッドなしで、事前に構成されたオブジェクトを提供します。
循環依存関係の優れたサポート。
傾く。フットプリントが非常に小さいため、CPU とメモリに制約のあるデバイスに適しています。
実戦テスト済み - あらゆる種類の Appstore 搭載アプリで使用されています
国際的に分散したコア チーム (私たちは StackOverflow も監視しています) のため、どんな質問にもすぐに対応できます :)
API ドキュメントとサンプル アプリ
品質管理:
また、強固な品質管理体制を維持しています。
NIB ファイルでオブジェクトをインスタンス化する必要はありません。ファイルの所有者をオブジェクトのクラスに設定し、ビュー/ウィンドウ/それまでのものをリンクすると、nibファイルを手動でロードすることにより、実行時にオブジェクトを所有者として設定できます。そうすれば、依存関係が適切に注入されたオブジェクトの動的インスタンスを持つことができます。
Objective-IOCでの依存性注入の実装についてはどうですか
ObjectivePim はどうですか? ObjectivePim
私は非常に単純な DI コンテナーを作成しました。コードはGitHubにあります。つまり、基本的なことしかできません。オブジェクトの依存関係を発見し、他の特定のオブジェクトを使用してそれらを満たします。実際のアプリケーションで使用できるようにするには、コードが非常にシンプルで、ハックするのが楽しいことがわかりました。
Interface Builder は依存性注入を一切行いません。その必要はありません。Interface Builder はオブジェクトをシリアル化します。nib が「目覚めた」(つまり開かれた) 場合、解決する「依存関係」はありません。設定するプロパティがあるだけです。とてもとてもシンプルです。nib を開くには、NSCoding プロトコルとキーと値のコーディングのみに依存します。
依存性注入は、最良の場合はほとんどメイクワーク プロジェクト、またはせいぜい独立して設計されたコンポーネント間の一般化された接着層であり、適切に記述された Objective-C コードでは役に立ちません。必要のないツールを求めています。
Objective-C では、匿名サービスを必要とするソフトウェアがプロトコルを宣言します。その後、サービスはこのプロトコルを採用します。クライアントはサービスを動的プラグインとしてロードします。一方、サーバーがクライアントより前に作成された場合は、既存のインターフェースをプロトコルに適応させる新しいプラグインを作成するだけです。これは、実行時にインターフェースを「発見」(してください) するための中間データ駆動型システムを定義しようとするよりも手間がかからず、より簡単です。
DI の大きな秘密は、DI が母国語ではなく XML でコードを記述する方法であることだけにあるということは誰の目にも明らかではないでしょうか? XML が実際のプログラミング言語よりも優れたプログラミング言語である理由について、適切な議論を聞きたいと思っています。意味がありません。
Mac OS X 10.6の連想参照機能を見たことがありますか?
これにより、DIに似たものを構築するか、すでに持っている可能性があると思います。私が見た限りでは、オブジェクトで必要な参照は、objc_getAssociatedObject() を使用して手動で取得する必要があります。
マンフレッド
私は一日中Springで働いており、Groovyをチェックしました。私は決して XCode/Cocoa の専門家ではありませんが、IB は依存性注入を行うだけであり、Groovy が実際に行っているとさえ主張していません。
あなたは DI を探しているのではなく、よくコンパイルされた統合ライブラリのセットを探していると思います。これにより、他の人が入力した多くのコードを入力する必要がなくなります。何らかの理由で人々は「オープンソース」を「プラットフォームに依存しない」と見なす傾向があるため、Cocoa には Spring のようなフレームワークはないと思います。したがって、Cocoa は少し取り残されています。
ただし、必要に応じて、Cocoa で使用できる無料のオープン ソース ライブラリがいくつかあります。これらはすべて、CocoaDev のナイス リストにリストされています。
春ではないことはわかっていますが、お役に立てば幸いです。
DI は、動的バインディングを必要とするランタイム実行環境のプロパティです。私は Obj-C と Cocoa に非常に慣れていないので、順不同で話すことがあります。何かが欠けていない限り、Obj C をコンパイルするのではなく解釈するか、ランタイム環境を変更する以外に DI を実装する方法がわかりません。
IB の DI のような動作は、それで構築されたアプリに関連付けられたドメイン固有のランタイム環境があるためだと思います。
でも修正されてうれしいです。
カテゴリは mixin の実装のように見え、デリゲートへのメソッドの動的ディスパッチを可能にします。かなりクールで Java のインターフェイスの概念に似ていますが、詳細が異なり、次のように考えると、メンバー フィールドは定義できませんが、カテゴリで定数を定義できるかどうかはわかりません。