プログラミング作業の構造化
オブジェクト指向のプログラミングは、より良い方法でプログラムを構造化するだけでなく、プログラミング作業自体を構造化する助けにもなります。
ソフトウェアが何度も何度も試されるうちに、プログラムはいっそう大きく、いっそう複雑なものになり、作業を管理していく上での問題も大きくなります。当てはめるべき部品は多くなり、それを組み上げるために共同作業をする人たちも多くなります。オブジェクト指向のアプローチでは、デザインの段階だけでなく、組織化された作業においても、この複雑さうまくをあつかう方法を提供します。
コラボレーション
(*Collaboration)
複雑なソフトウェアは、個々にはクリエイティブであるべき人々へ、それまで彼らがやってきたことが他の人がやっていることと一緒にならないように、驚くほど協同的*であるよう努めるよう求めます。（*collaborative: コラボレーション的）
つぎ込まれる労力の規模と、同じ場所で同じ時間に同じプロジェクトに携わる人の多さは、共通のゴールに向かう協同的な仕事をする上での、グループとしての能力へ障害となって立ちはだかります。加えて、コラボレーションはしばしば、時間、場所、そして所属する組織によって妨げられます。
- コードは管理され、改善され、そして書かれてから長い時間に渡って使用されなくてはなりません。１つのプロジェクトでコラボレートするプログラマたちは、同じ時間に同じコードで作業しているわけではありませんから、議論する余裕もお互いに実装の詳細にまで説明して回るわけにはいきません。
- プログラマたちが同じプロジェクトの同じ時間に仕事をしていたとしても、彼らはおそらく同じ場所にはいないでしょう。このこともまた、いかにして彼らを密に共同作業をさせるかで妨げになります。
プログラマたちが違うグループで、違う優先度を持ち、違うスケジュールで仕事していても、しばしば複数のプロジェクトでコラボレートしなくてはなりません。組織の壁を越えたコミュニケーションは常に、簡単には解決しません。
これら難点への答えは、プログラムがデザインされ書かれる方法の外側で導かれなくてはなりません。階級制度的な管理構造や権限の厳格なレベル分けといった形で、外部らか押しつけてはいけません。これらはしばしばプログラマたちの創造性に口を挟み、自身の中にも、自身にとっても重荷となります。それよりも、コラボレーションは仕事自体の中に組み込まれていなければなりません。
これがまさに、オブジェクト指向のプログラミングテクニックが手を差し伸べられるところです。たとえば、オブジェクト指向のコードは再利用が可能なので、プログラマは効果的にコラボレートできます。彼らが違う時間に違うプロジェクトに取り組んでいるときや、違う組織に属していたとしても、ライブラリにある彼らのコードを共有すればコラボレーションできるのです。この種のコラボレーションは多くの可能性、困難な仕事を見た目は明るくし、不可能なプロジェクトを表面上は成し遂げられるものにするといった力を持っています。
オブジェクト指向プロジェクトを組織する
オブジェクト指向のプログラミングは、プログラミング作業を再構成して、コラボレーションが有益なものとなるよう手助けします。また、低いレベルの実装においてコラボレートする必要性を取り除く手助けをする一方で、高いレベルでコラボレートできるよう推進する構造を提供できます。オブジェクトモデルのほとんどすべての特徴は、コードをよりいっそう再利用可能なものへとできる、広範囲にわたるデザインに由来しており、プログラマたちが共同して仕事ができる結果をもたらします。
大きなスケールでデザインする
プログラムが高いレベルの抽象性を目標としてデザインされれば、苦労させられる部分はもっと簡単なことだと思えます。また、プログラムする部分が論理的な部分と一致してきます。プロジェクトが組織される方法は、デザインから離れたところで拡がることができます。
オブジェクト指向のデザインを取り入れれば、共通のゴールを常に視界に入れておくのがたやすくなり、実装作業の中でゴールを失わず、関わるすべてのひとが、自分が取り組んでいる部分が全体の中でどこに当てはまるのかをたやすく把握できます。したがって、彼らの協同的な取り組みは、より一層と目標へ向かったものになります。
実装からインターフェイスを分離する
オブジェクト指向のプログラムにおいて、さまざまなコンポーネントをつなぐコネクションは、デザイン段階の早いうちに設計します。それらコネクションはよく練られて定義されるべきで、少なくとも開発の初段階、実装が始まる前に行います。
実装段階においては、インターフェイス部分とだけ整合性をあわせる必要があり、実装のほとんどが自然とデザインから外れていきます。どのクラスも自身の実装をカプセル化しており、また自身の名前空間を持つので、実装の詳細については整合性をあわせる必要はありません。コラボレーションへの要求がほとんど無ければ、コラボレーションはシンプルになります。
作業をモジュールへ分けていく
オブジェクト指向のプログラミングにおけるモジュラー性は、大きなプログラムでの論理的なコンポーネントがそれぞれ別々に実装されるのを意味します。それぞれ違う人たちが、それぞれで違うクラスで仕事ができます。どの実装作業も、他の人のとは隔離されています。
モジュラー性にはいくつかの利点があります、実装を組織化するために限らず、のちに問題を修正するためにも。実装はクラス境界の中側に含まれているので、発生する問題もまた同じように隔離されています。実装が、プログラムの中にある、よく練られて定義された部分に位置していたら、容易にバグを探し出せます。
クラスを導入することで、責任を分離できるということはまた、プログラムのどの部分も、その方面の専門家の元で作業されるということです。クラスのパフォーマンスを最適化したり、新しい技術を最善の方法で利用したりできるよう、定期的にアップデートできます。これらアップデートは、プログラムの他の部分と調整をとる必要はありません。オブジェクトのインターフェイスが変わらない限り、実装の改良はいつでも組み込むことができます。
インターフェイスはシンプルに保つ
オブジェクト指向のプログラムがポリモーフィズムであることは、よりシンプルなプログラミングインターフェイスをもたらします。というのは、同じ名前、同じ規定を、どんなクラスへでも、再利用できるからです。ここから得られる結果は、少ない学習量、全体のシステムがどうやって動くのかを幅広く共有する理解、そして協力体制と共同体制へのシンプルな方針です。
決定は動的に行う
オブジェクト指向のプログラムはランタイムに動的に決定を下すので、２つのコードを共同作業させるのにコンパイル時（ソースコードで）に、それほど多くの情報をあたえる必要はありません。結果として、調整の必要は減り、悪いものなるのも少なくなります。
ジェネリック*なコードを継承する
（*包括的な、一般的な）
継承は、コードを再利用する方法です。何かに特化したクラスを、より一層ジェネリックなクラスへと定義できれば、プログラミング作業はより簡単になります。そのうえ設計もシンプルになります。というのは継承階層は、異なるレベルの実装にあるクラス間の関連性を適切に配置し、それらをより理解しやすいようにするからです。
継承はまた、コードの再利用性と信頼性を向上させます。スーパークラスにあるコードは、そのサブクラスでテストされます。ライブラリで見つかるジェネリックなクラスは、他のディベロッパが他のアプリケーションのために書いたスーパークラスで試されてきたはずです。
テストされたコードを再利用する
あなたが他の人から借用でき、あなたのプログラムへ組み込めるプログラムほど、あなたが自身でしなければならないことは少なくなります。オブジェクト指向のプログラミング環境において、借用できプログラムほどその傾向があります。なぜなら、そのコードは再利用性がより高いからです。異なった場所で、異なった組織で働くプログラマたちでのコラボレーションは一層と高められ、同時にどちらのプロジェクトでの苦労は軽くなります。
オブジェクト指向のライブラリからもたらされるクラスとフレームワークは、実のある貢献をあなたのプログラムへあたえます。たとえばAppleから提供されたソフトウェアフレームワークを使ったプログラムであるときは、Appleのプログラマと効果的にコラボレートができます。あなたは、あなたのプログラムの一部、しばしば実質的な部分、を彼らに引き受けさせられます。あなたは１番すべきことへ集中でき、そのほかの仕事はライブラリ開発者へ任せっきりにできます。あなたのプロジェクトは試作段階でより早くなり、完成品ではさらに早くなります。あなた自身の場所で協同的に挑戦をすることなく、です。
オブジェクト指向のコードの再利用性が高くなるとまた、その信頼性も高まります。ライブラリから持ってきたクラスは、バラエティに富むアプリケーションや状況へ利用できる可能性があります。コードがより使われるにつれて、多くの問題が発生し尽くし、それらが既に修正されている可能性がより高まります。あなたのプログラムにおいて、まだ見つかっておらず、かつ見つけるのが難しいバグは、すでに取り組み済みで、取り除かれています。
Referred from
Object-Oriented Programming with Objective-C, Structuring Programs
Copyright
Copyright © 201 Apple Inc. All Rights Reserved. Terms of Use | Privacy Policy | Updated: 2010-11-15