コンセプトを働かすエンジンだということができます。これは、オブジェクト仲介人の役割を演じることも含まれています。一般に、インタフェースはジョブを行うために使われることのできるオブジェクトを記述します。インプリメントをリクエストする必要があります。そのインプリメントは他のコンポーネントの範囲内に属することが出来ます。細部まで定義されたインターフェースを使用することで利用しやすくなる、インプリメントの動作上の契約です。インプリメントされているか、どのコンポーネントがそれを提供しているかを知っています。いずれにせよとてもしばしば使われます。一つの理由は柔軟さにあります。ロジックのある部分と機能を共有することを許すためです。呼ばれる技術を提供しています。オブジェクトのインスタンスが必要なときにはいつでも、クラスオブジェクトは作成され、インタフェースのポインタが与えられます。いくつかの理由でこれらのインスタンスが参照をカウントされることが決められました。一つの理由は効率です。そのために、オブジェクトの不要なコピーは省かれるべきです。他の理由は、データオブジェクトはスレッド間で渡されるべきですが、すべてがメモリ上の同じデータオブジェクトに対するポインタを維持するためです。最後に、同じデータオブジェクトは多数のコンポーネントに参照されたり、多数のリストに貯えられたりすべきだからです。参照の生存期間は異なるため、どのくらいしばしば現在何かに参照されているという状態であるか覚えておくためには、それぞれのオブジェクトが参照のカウントを保持するのが最も簡単な方法です。エンジンによる直接参照もしくは、関数呼び出しによって)、リファレンスのカウントのケアを確実にする必要があります。オブジェクトへの参照を維持するかどうかや、参照を終えられるかどうかを教え、参照を削除しなくてはなりません。そのように、オブジェクトはそれがまだ必要とされているかどうかを自分自身で判断することが出来ます。オブジェクトがもう不要なら、自分自身でメモリから削除します。いう共通基礎クラスを共有しています。インプリメントにも存在します。しなければならない、という一般的なルールがあります。参照を追加したいとき、もう不要となったときすぐさま参照を解放することを強く促します。しなければメモリリークといった問題を引き起こすことになるでしょう。基本クラスのメソッドの明白なメソッド呼び出しによって行われます。それらのメソッド呼び出しは、忘れやすいだけでなく、コードの可読性も低下させます。関数やメソッドの出口毎にすべてのオブジェクトへの参照を解放することを確実にしなければなりません。オブジェクトへのポインタを扱うために提供されています。コーディングをより楽にします。これは、特定のオペレータのオーバーライドを通してポインタをシミュレートします。いくつかの例外的ケースがありうるにも関わらず、このような一般的なルールはほとんどすべてのコードで守られています。なったらすぐに、可能ならデストラクタが自動的に参照カウントを減らします。これはコード上で簡単に行えます。それは、ガベージコレクションのためです。可能なときに参照を自動的に減少させる魔法があるのです。この魔法は循環参照しないことを必要とします。二つのオブジェクトがあり、お互いへの参照を含んでいても、他のオブジェクトがそれらを参照していないとき、それらのオブジェクトは検出されません。それらのオブジェクトはプログラム実行の残りの間メモリに存在しつづけます。nsresultコード実行が実行時に失敗することもあります。部分では使っていません。以前やったことがスタックの中にあるため、例外はいつでもポータブルというわけではないというのが、そのいくつかの理由のうちの一つです。コードは戻り値で例外を真似ています。中では、インタフェースのメソッドを使う場合はいつでも戻り値を見なくてはなりません。コードの中の追加のメソッドのパラメータにマッピングされています。型は、失敗理由の付加情報も運ぶことを意図しています。成功か失敗かという単純なレポートの代わりに、整数型を使い、多くの異なったエラーコードを定義することを許しています。いくつかの戻り値があります。何か異常が発生しているけれども、今のところそれ以上の詳細は必要ないといった場合に使われます。それに加え、互いのコンポーネントはアプリケーションの他のエリアで使用していない失敗コードを上書きしないエラーコードの定義をするために、独自の範囲の整数をリクエストすることが出来ます。開発者は、文字列により強力な機能を求めました。実行時の動的な振る舞いを異なったシチュエーションのために最適化することを許すために、いくつかの文字列クラス階層をインプリメントしました。時には文字列のサイズを変更するだけでしょうし、時には、自動的にサイズが大きくなる文字列が必要でしょう。そのため、たとえば、ただの平坦な文字列ではなく、断片化された文字列型も使用可能です。完全な多言語対応をしなくてはならないということです。文字列を使っています。文字列を使うのを同じロジックで扱えるようにしています。開発するための独自の方法を定義していて、それぞれたいてい異なっています。依存のロジックを隠すテクノロジーをもつということは、重大なことです。ライブラリはクロスプラットフォームに書かれてきました。しても、独自のグラフィックシステムを作りました。レイアウトを定義するとき、二つの可能性のいずれかを共にするかを選ぶことが出来ます。要素の絶対位置を定義する方法があります。ライブラリで選ばれています。これには欠点があります。エレメントが加わってレイアウトが変わったとき、十分な柔軟性がないことです。それは、すべての要素を新しい位置に計算し直す必要があるからです。それは、どのエレメントが重なっているかなどのフィードバックをいちはやく得るために、よりグラフィカルにしなくてはなりません。異なるメトリクスをもつフォントが使われなくてはならないとき、意図したように見えないかもしれません。使い物にならないと判断させます。開発者は、より柔軟性のあるものを求めました。クロスプラットフォームなので、フォントにより注意を払う柔軟性を備えることが必要です。コンテンツがデザインされたところというアプローチを使うことを選びました。エディタを使っていません。みえるべきかを指示するファイルを書きました。ページをどのように表示するかと似ています。大部分がテキストベースのシステムから多くのプログラムのようなユーザインタフェースをもつとてもグラフィカルで裕福な環境へ移り変わってきました。言語を使うことはもっとも自然なことです。構成しているか、どこに要素が現れているかを記述します。言語は制御に反応してどういう働きがあるかをプログラマが定義することを許す属性を定義します。関数を定義することが出来ます。オブジェクトの利用可能な他のアプリケーションロジックを呼び出すかすることが出来ます。かわいらしい見た目を望んだりもします。これは、"テーマ"や"スキン"を参照するアプリケーションのための追加の"ルックス"の定義を柔軟にします。開発者によって活発にメンテナンスされている「クラシック」と「モダン」という2つの「テーマ」が定義されています。存在するということです。毎日起こるすべての変化に同期をとりつづけることは、「テーマ」のデザイナにとって大きな仕事です。実行時に必要に応じて動的にロードされた多くの共有ライブラリの集まりのように使われています。システムによって、ソースコードの複数の場所を変更した場合でも、再コンパイルする必要があるのはアプリケーションの一部だけで良い場合が多い、という開発環境が可能となっています。これは、とても便利な開発環境です。これは実行の速度低下を意味します。バイナリを作ることも可能です。アプリケーションのサイズのため、このリンクステップには多くの時間がかかります。ディストリビューション向けのパッケージを準備するときに、この意味が良くわかるでしょう。ルートディレクトリの中に持ちます。それはまた、呼び出したモジュールの範囲内でサブのコンポーネントを持つということです。プラットフォーム依存のコードのほとんどは、ツリーの少しの場所にだけ含まれます。他のコードの間にあるレイヤーはこのコードによってインプリメントされたインタフェースです。ビルドが発生するものの中のプラットフォームを準備するプラットフォーム依存のコードだけがビルドされます。メッセージはプラットフォーム依存のコードによって集められています。同じ方法でプラットフォームに独立したコードへ送られます。名づけられたディレクトリはたいていインタフェースのインプリメントやインタフェースのヘッダでないものを含みます。このプログラムのビルドはこのように大きなプロジェクトに慣れない人をひるませるかもしれません。時間はかかるでしょう。ソースを入手しなくてはなりません。含まれるルールを使ってそれをビルドします。ディレクトリに移動するでしょう。コピーされるでしょう。ファイルだけが含まれるでしょう。ビルドするというのは、プロセスの一部に過ぎません。呼ばれるプログラムを使ったツリーのメンテナンスをしなくてはなりません。ビルドに失敗した時には、あなたのツリーの中のファイルとレポジトリの中のファイルとの結合が失敗した際に生じた競合を解消しなくてはなりません。ツリーをハックするとき、修正したツリーの部分をビルドしなくてはなりません。呼ばれるプロセスを使ってツリー全体を再ビルドしなくてはならないでしょう。ソースファイル間の依存を決定しなくてはならないからです。ツリーを再ビルドするでしょう。これをしている間、ツリーへの自身の行った変更をメンテナンスしていて、他人の変更と同期をとろうとしているでしょう。システムは、タイプライブラリと、実行可能なコンポーネントの内部レジストリと、インタフェースに頼っています。アプリケーションを開始している間、レジストリが今も最新のものかのチェックが行われます。変更されたライブラリを検知したとき、レジストリは更新されます。それぞれのコンポーネントはそのレジストレーションフェーズの間に初期化を行うことが許されます。変更されたライブラリを検知したとき、それらはロードされ、初期化ロジックが実行されます。変更ライブラリに加え、それらのアプリケーションコンポーネントだけが必要とされたようにロードされます。内部で利用可能な機構について記述します。めったにこれは必要になりません。特定のイベントに対処する必要のある時には、このシステムを知ることが助けとなるでしょう。考え方は、各々が各々自身の役割を果たすことというものです。それに対応しなくてはなりません。それを起こすのに何が必要かの詳細を知るべきではないのです。ここで必要なのは、次のような事です。そのアクションに対する引き金が引かれたら通知を送信するように拡張されるべきです。誰が通知されるのを待っているか覚えているリストを実行時に動的に保持します。通知リストの対象に加えてほしいと告知します。使うことを決めました。アクションの引き金を引いたとき、観察サービスにすぐに通知し、記述的にイベントの名前を明確にします。ようなコンポーネントは観察サービスに観察したいイベントの名前をもらえるよう申請します。その原則を使用し、観察サービスだけがイベントを見るコンポーネントのリストを扱わなくてはなりません。観察サービスはイベントの通知を受けると、その通知を、そのイベントへのすべてのコンポーネントリストに引き渡します。人間の言語からコードを分離するデザインがされています。ファイルの中に直接文字列を保存することは許されません。コードで使われるテキストのために記述的識別子を定義します。その識別子をキーとして使い、実際のテキストを取り出すための文字列集合インタフェースのメンバーを呼び出します。テキスト自身はテキストだけ格納された分離されたファイルに格納されます。モジュールの集合であるため、多くのファイルがあり、分離されたモジュールにそれぞれ所属します。その分離にともなって、翻訳者がテキストファイルの言語別バージョンを作るのが簡単なのです。種類の文字列があります。ある文字列は、入力フィールドのテキストやヘルプの中にだけ出てくるテキストのようにアプリケーションがコンパイルされ、パッケージ化されたその時に知られるもので、またある文字列は、実行時に動的に組み立てられます。ファイルの中に定義してください。ファイルの中でそのテキストを直接参照することが出来ます。ファイルにテキストを定義してください。ダウンロード、コードの変更、独自の変更を含むバージョンでの作業などがフリーで行えます。使われているオープンソースの背後にある一つの考え方に次のようなものがあります。ソースをフリーで入手できるかわりに、ソースに変更を加えたら、コミュニティに何がしかの還元を考えるべきです。することにより、貢献者となるのです。コードに組み込まれるという変更をただ受け入れることは出来ないと決定しました。自分のコードをその中の一部にしたければ、次のようなルールに従わなければなりません。それは法律のようなものではありません。基本的に、あなたは、あなたの変更が良いものであると他の人々が認めるよう説得しなければなりません。コードをより正しい状態にするために作られた多くの効果があります。コードはどのソフトウェアの一部と同様に、完璧からはほど遠く、人々は保守性を低下させるものは何でも取り除こうとし、正しいと思われるコードだけを受け入れます。ハッカーたちに受け入れられる必要があると決めました。ここに2つの段階のレビューがあります。受ける必要があります。要求された修正を行うことが期待されます。なければここで終わりです。呼ばれるレビューを受ける必要があります。いう、どのコードがよく、どこを変更するべきかについての判断が優れていると認められている人々がいます。一度、両方のレビューを受ければ、ほとんどの場合、コードはチェックインされます。ある特定の事例では、他のレベルのレビューがあり、それは別の場所に記述されます。しようとする一方、どの変更も思いがけない面への影響というリスクがあります。ソースコードがコンパイルできなくなるといった単純な問題にまで及びます。注意を払っていないとき、ツリーは簡単に壊れてしまいます。ツリーを壊さないためにベストを尽くす必要があり、レビューを受けることで、願わくば、変更点をチェックインするより早く潜在的な問題を発見したいのです。コミュニティは、ツリーが壊れている間ほかのチェックインを許さないというルールを決定します。これは、この問題を修正する人を助けます。ほかの変更を許すことは、新しいチェックインがあたらしい問題を含んでいるかもしれないために、問題のほんとうの原因を見つけることを難しくします。ソースレポジトリの新しいスナップショットを出します。報告すべきだというものです。それらのマイルストーンはテスト目的だけのために出されたということを強調したいのです。安定したマイルストーンを準備するために、ソースコードレポジトリを変更するためのルールは、新しいマイルストーンを準備する前にはより厳格なものになります。"ドライバ"と呼ばれる人たちに認可されたチェックインだけが許されます。レポジトリに関して、最高の権限をもっている人の集団です。ドライバはまた、マイルストーンが準備できているのか、よりマイルストーンを安定させるためにマイルストーンを出すためより多くの修正を許すために日程を遅らせるかどうかも決定します。ベースのバグ追跡システムです。詳細に何が起こったかとともに申し立てるよう依頼されます。バグが公表されるなり、番号を発給するなりします。この番号は問題について話されるときに使われます。開発者は"バグ"について署名し、コメントします。修正方法を知っていればどのように問題の修正方法を提案するかを見せるために、パッチを添付するでしょう。レビューも、このシステムの内部で進みます。バグという単語はしばしばソフトウェアのエラーという意味にみなされます。内部では、バグは追跡されるべきものとなります。これはソフトウェアのエラーから、機能拡張のリクエストに及びます。