オブジェクト指向設計に関する注意事項 |一部--＆＃＆チュートリアル-php.cn

パート 1 - オブジェクト指向の分析と設計

1. オブジェクト指向の考え方

オブジェクト指向の思考はオブジェクト指向モデリングの基礎であり、これがこの投稿の中心的な側面です。これには、問題と概念を構成要素に分解し、これらの部分をオブジェクトとして考慮することで理解することが含まれます。

定義: オブジェクト指向の思考とは、さまざまな要素を個別のオブジェクトとして見ることを意味します。たとえば、ソフトウェアシステムでは、ツイート、ユーザー、または製品をオブジェクトとして見ることができます。
属性と動作:
- 属性: オブジェクトのプロパティまたは特徴 (人の名前、年齢、身長など)。
- 動作: オブジェクトが実行できるアクション (デバイスの電源オンまたはオフ、ユーザーのログインなど)。
メリット:
- 組織: オブジェクトはデータと動作の両方をカプセル化し、関連する詳細と機能をまとめます。
- 柔軟性: オブジェクトの属性や動作の変更は、他のオブジェクトとは独立して行うことができます。
- 再利用性: オブジェクトはプログラムのさまざまな部分または異なるプログラム内で再利用できるため、作成および保守する必要があるコードの量が削減されます。

2. ソフトウェアプロセスにおける設計

設計フェーズはソフトウェア開発ライフサイクルにおいて重要です。これにより、最終製品がユーザーの要件を満たし、意図したとおりに機能することが保証されます。

ソフトウェア開発プロセス: ソフトウェア開発プロセスは反復的であり、いくつかの重要な段階が含まれます。
1. 要件の収集: クライアントまたはユーザーがソフトウェアに何を必要としているかを理解します。
2. 概念設計: 高レベルの設計概要とモックアップを作成します。
3. 技術設計: 各コンポーネントの詳細な仕様を作成します。
4. 実装: 設計に基づいて実際のコードを記述します。
5. テスト: ソフトウェアが正しく動作し、要件を満たしていることを確認します。
6. 展開: ソフトウェアを使用できるようにリリースします。
7. メンテナンス: 継続的なアップデートとバグ修正。
設計の重要性: 設計フェーズを省略したり、設計フェーズに不適切に対処したりすると、プロジェクトの失敗につながる可能性があります。強固な設計基盤があれば、ソフトウェア開発が正しい軌道で開始され、後でコストのかかる変更が発生するリスクが軽減されます。

3. 要件

要件の収集はプロジェクトの成功の基礎です。これには、クライアントまたはユーザーがソフトウェアに何を必要としているかを理解することが含まれます。

定義: 要件とは、ソフトウェアが満たさなければならない条件または機能です。
引き出し:
- クライアントインタビュー: クライアントと直接話し合い、クライアントのビジョンとニーズを理解します。
- アンケートと調査: 潜在的なユーザーまたは関係者から構造化された情報を収集します。
- 観察: ユーザーが現在のシステムとどのように対話するかを観察して、ニーズと問題点を特定します。
- ワークショップ: 要件を収集し、優先順位を付けるための関係者との共同セッション。
トレードオフ: クライアントは、さまざまなニーズと制約のバランスを取る必要がある場合があります。たとえば、より多くの機能か、より迅速な配信のどちらかを選択する必要があるかもしれません。

例: 住宅を設計するとき、建築家は部屋のサイズ、配置、特定の機能について住宅所有者の好みについて詳細な質問をして要件を収集します。これにより、建設中のコストのかかる変更を防ぐことができます。

4. デザイン

ソフトウェア開発における設計には、実装フェーズをガイドする概念的な青写真と技術的な青写真の両方の作成が含まれます。

コンセプトデザイン:
- 定義: ソフトウェアの主要コンポーネントとその役割の概要。
- モックアップとワイヤーフレーム: 詳細な作業を開始する前に、関係者がデザインを理解し、承認するのに役立つ視覚的表現。
- 責任: ソフトウェアの各コンポーネントが何を行うべきかを定義します。
- 例:
- モックアップ: 画面の外観と機能を示すユーザーインターフェイスの視覚的なレイアウト。
- ワイヤーフレーム: 詳細な設計要素を含まないコンポーネントのレイアウトを示す単純なスケッチまたは図。
- 重要性: すべての関係者がソフトウェアの高レベルの構造について明確に理解し、合意していることを確認します。

例: 家を建てる場合、概念設計では部屋の一般的なレイアウトとその接続の概要が示されますが、配管や配線についてはまだ詳細が説明されていません。

技術設計:
- 定義: 各コンポーネントの詳細な仕様 (コンポーネントの構築方法や相互作用の方法など)。
- 技術図: コンポーネントがどのように組み合わされ、コンポーネント間でデータがどのように流れるかを示す詳細な図面。
- コンポーネントの分割: それぞれを実装できるようになるまで、高レベルのコンポーネントをより小さく管理しやすい部分にさらに分解します。
- 例:
- クラス図: クラスの構造、その属性、メソッド、関係を示します。
- シーケンス図: 特定のイベントシーケンスでオブジェクトがどのように相互作用するかを示します。
- コンポーネント図: コンポーネント間の構成と依存関係を示します。
- 重要: コードを効果的に作成するために必要な詳細情報を開発者に提供し、開発チーム全体での一貫性を確保します。

例: 住宅建設では、技術設計で壁、床、屋根の正確な材質と、配管や電気システムの詳細な計画が指定されます。

5. 要件と設計の妥協

設計プロセス全体を通じて、クライアントのニーズとプロジェクトの制約のバランスをとるために妥協が必要になることがよくあります。

コミュニケーション: デザインがクライアントのビジョンや制約と一致していることを確認するには、クライアントとの継続的なフィードバックループが不可欠です。
- 反復レビュー: クライアントの意見をもとにデザインを定期的にレビューし、改良します。
- プロトタイピング: クライアントとアイデアをテストおよび検証するためのコンポーネントの初期バージョンを構築します。
再作業: 要件を満たしていない場合、または実現不可能であることが判明した場合は、概念設計と技術設計の両方を修正する必要がある場合があります。
- 柔軟性: 新しい情報が出現したり、要件が進化したりした場合でも、変更や調整を柔軟に受け入れます。
- 影響分析: 情報に基づいた意思決定を行うために、プロジェクト全体に対する変更の潜在的な影響を評価します。

例: クライアントがオープンキッチンを望んでいるが、構造上のニーズにより支持梁が必要な場合、建築家とクライアントは、クライアントの美的好みを満たしながら構造の完全性を維持する妥協点を見つける必要があります。

6. 品質特性を考慮した設計

ソフトウェアの設計には、機能要件と非機能要件の両方を満たすために、さまざまな品質特性のバランスをとることが含まれます。

品質属性: ソフトウェアのパフォーマンス、使いやすさ、保守性に影響を与える特性。
- パフォーマンス: ソフトウェアがタスクを実行する速度と効率。
- セキュリティ: ソフトウェアを脅威や脆弱性から保護するために講じられる対策。
- スケーラビリティ: 増加した負荷または使用量を処理するソフトウェアの能力。
- 保守性: ソフトウェアをどれだけ簡単に更新または変更できるか。
- ユーザビリティ: ユーザーがソフトウェアを学習して使用する際の容易さ。
トレードオフ: 1 つの属性を最適化すると他の属性に影響を与える可能性があるため、これらの属性のバランスをとることには多くの場合トレードオフが伴います。
- パフォーマンスとセキュリティ: セキュリティ対策を強化すると、パフォーマンスが低下する場合があります。
- スケーラビリティと使いやすさ: スケーラビリティを向上させるために機能を追加すると、ユーザーインターフェイスが複雑になる可能性があります。
コンテキスト: ソフトウェアの特定のコンテキストは、これらの属性のバランスがどのように保たれるかに影響します。
- 重要システム: 他の属性よりも信頼性とセキュリティを優先します。
- コンシューマアプリケーション: ユーザー満足度を高めるために使いやすさとパフォーマンスを重視します。

例: 玄関ドアを設計するときは、セキュリティ (頑丈なロック) と利便性 (アクセスの容易さ) のバランスをとることが重要です。ロックが多すぎるとドアは安全ですが不便になり、ロックが少なすぎると便利ですが安全性が低くなります。

7. 集団責任協力者 (CRC) カード

CRC card

CRC カードは、設計プロセスにおいてクラス、その責任、および協力者を識別して整理するために使用されるツールです。

定義: CRC カードは、さまざまなクラスの責任と、クラスが相互にどのように相互作用するかを視覚化して整理するのに役立ちます。
- クラス: システム内のオブジェクトまたは概念を表します。
- 責任: クラスが知っていることと実行することを定義します。
- コラボレーター: クラスが対話する他のクラス。
使用法:
- ブレインストーミング: チームがブレインストーミングを行い、必要なクラスとその役割を特定するのに役立ちます。
- デザインセッション: クラスの責任と相互作用についてのディスカッションを促進します。
- ドキュメント: 設計上の決定事項を記録するためのドキュメントツールとして機能します。
プロセス:
- クラスの識別: システムに関与する可能性のあるクラスをすべてリストします。
- 責任の定義: 各クラスの主な責任を書き留めます。
- 協力者の特定: 各クラスが責任を果たすためにどのクラスと対話する必要があるかを決定します。
メリット:
- 明瞭さ: デザインのアイデアを整理して伝達するための明確かつ簡潔な方法を提供します。
- 柔軟性: 設計の進化に応じて簡単に更新および変更できます。
- コラボレーション: 設計上の決定についての議論や改良が容易になり、チームのコラボレーションが強化されます。

例: 銀行アプリケーションでは、「Account」クラスの CRC カードに「残高の管理」や「トランザクションの追跡」などの責任がリストされ、「Customer」クラスや「Transaction」クラスなどのコラボレータが含まれる場合があります。 .

8. プロトタイピングとシミュレーション

プロトタイピングとシミュレーションの手法は、プロセスの初期段階で設計をテストして改良するために使用され、本格的な開発前に問題を特定して修正するのに役立ちます。

プロトタイピング:
- 忠実度の低いプロトタイプ: ソフトウェアまたは特定のコンポーネントの単純で大まかなバージョン。多くの場合、紙または基本的なデジタルツールを使用して作成されます。
- 高忠実度プロトタイプ: 最終製品に非常に似た、より詳細でインタラクティブなバージョン。
- 目的: 設計コンセプトを検証し、ユーザーからのフィードバックを収集し、ユーザビリティの問題を特定します。
- メソッド:
- ペーパープロトタイピング: ユーザーインターフェイスとインタラクションの手描きのスケッチを作成します。
- デジタルプロトタイピング: ソフトウェアツールを使用して、インタラクティブなモックアップやシミュレーションを作成します。
シミュレーション:
- 定義: モデルを実行して、さまざまな条件下で設計の動作とパフォーマンスをテストします。
- ユースケース: システムパフォーマンスの評価、負荷テスト、設計上の決定の検証。
- メリット:
- 早期検証: 本格的な開発の前に潜在的な問題を特定します。
- 費用対効果が高い: 問題に早期に対処することで、コストのかかる変更のリスクを軽減します。
- ユーザーフィードバック: ユーザーがプロトタイプを操作し、機能や使いやすさに関するフィードバックを提供できるようにします。
- ツール: プロトタイプの作成やシミュレーションの実行には、さまざまなソフトウェアツールとプラットフォームが利用できます。