O slideshow foi denunciado.
Utilizamos seu perfil e dados de atividades no LinkedIn para personalizar e exibir anúncios mais relevantes. Altere suas preferências de anúncios quando desejar.

オブジェクト指向入門2

683 visualizações

Publicada em

ソフトウェア基礎講座資料

Publicada em: Educação
  • Seja o primeiro a comentar

  • Seja a primeira pessoa a gostar disto

オブジェクト指向入門2

  1. 1. オブジェクト指向 プログラミング入門 ソフトウェア基礎講座 第2回 2011年2月16日 服部健太
  2. 2. 2011/2/16 モジュール性  モジュール性が高いソフトウェア  拡張性が高い  再利用性に優れる  具体的にはどういうことか?  何を「モジュール」とするかは言語やシステ ムに対する見方によって異なる  サブルーティン,クラス,パッケージ,プロセ ス,・・・  これらは広い意味でのモジュール
  3. 3. 2011/2/16 モジュール性の5つの基準  モジュール性を高める設計手法の必要条件  分解しやすさ( Decomposability )  組合せやすさ( Composability )  分かりやすさ( Understandability )  連続性( Continuity )  保護性( Protection )
  4. 4. 2011/2/16 モジュールの分解しやすさ  作業が分割でき,複数人での並行開発が可能 になる  依存関係を最小限にする必要がある  依存関係をあらかじめ知っておく必要がある あるソフトウェア構築手法が,ソフトウェアの問 題を,単純な構造によって組み合わされ,個別に 作業を進められるだけの独立性を保った,少数の より複雑ではない問題に分解するのを助けるとき ,その手法は「モジュールの分解しやすさ」の基 準を満たす.
  5. 5. 2011/2/16 分解しやすさの悪い例  作成するすべてのソフトウェアシステムの中 にグローバルな初期化モジュールを入れてし まう  初期化モジュールは他のモジュールの内部構 造を覗かなくてはならなくなる Initializer Module A Module B Module C
  6. 6. 2011/2/16 モジュールの組合せやすさ  再利用性を促進する  いろいろな場面で利用可能なソフトウェアの部品を設計す る  分解しやすさと相容れないこともある  トップダウン vs ボトムアップ ある手法が,もともと開発されたのとは全く異な る環境においても,互いを自由に組み合わせるこ とにより,新しいシステムを製作できるようなソ フトウェア要素の生産を助けるならば,その手法 は「モジュールの組合せやすさ」を満たす.
  7. 7. 2011/2/16 例  サブプログラムライブラリ  様々なライブラリを組み合わせて使うことができ る  行列演算,ソケット,グラフィクス, etc  Unix のシェル規約  様々なコマンドをパイプでつないで組み合わせら れる  cat, grep, wc, sed, sort, ・・・  悪い例:プリプロセッサ  複数のプリプロセッサで互換性が無い  データベースのプリプロセッサ( Pro*C/C++ ) とグラフィックス用のプリプロセッサ( Qt )を
  8. 8. 2011/2/16 モジュールの分かりやすさ  ソフトウェアの保守性を高める  モジュールに関する情報はモジュールの中に 埋め込んで置くとよい(自己文書化) ほかのモジュールの知識を必要とせずに,あるい は最悪でも,ほかのわずかなモジュールについて 知るだけで,読み手が理解できるソフトウェアの 生成を助ける場合,その構築手法は「モジュール の分かりやすさ」を高める.
  9. 9. 2011/2/16 悪い例  順序に依存する場合  特定の決められた順序で起動しないと上手く機能 しない設計  A B C⇒ ⇒  A と C を理解しないと B は理解できない
  10. 10. 2011/2/16 モジュールの連続性  拡張性の高いソフトウェアを構築できる  インクリメンタルな開発手法が使える  小さな変更がシステム全体の構造に影響を与えな い ある手法によって生み出されたソフトウェアアー キテクチャ内で問題の仕様に小さな変更が生じた 際に 1 つまたは少数のモジュールの変更しか引き 起こされない場合,その手法は「モジュールの連 続性」を満たしている.
  11. 11. 2011/2/16 例  シンボリック定数  マジックナンバーを使わずにマクロや定数定義を 用いる  統一形式アクセスの原則  オブジェクトの属性は統一した仕方でアクセスで きるようにする( getter と setter )  悪い例:物理的表現の使用  データの物理的実装に依存したプログラム  悪い例:静的配列  事前に配列の大きさを決めなくてはならない
  12. 12. 2011/2/16 モジュールの保護性  実行時エラーの問題  ハードウェア故障,誤入力,リソース不 足,・・・, etc.  エラーの伝播と増殖を抑えたい ある手法が,実行時にモジュール内で発生した異 常な条件のそのモジュール内に閉じ込めることが できるか,最悪周辺の少数のモジュールにしか影 響が広がらない場合,その手法は「モジュールの 保護性」を満たしている.
  13. 13. 2011/2/16 例  入口で入力を検査する  入力データの妥当性を常にチェックする  悪い例:制御されていない例外処理  例外がモジュール境界を越えて伝播していく  例外は出さないほうが良い  発生した例外はきちんとキャッチして正しく処置 すべし
  14. 14. 2011/2/16 モジュール性の5つの規則  モジュール性を保証するために守るべき規則  直接的な写像( Direct Mapping )  少ないインタフェース( Few Interfaces )  小さなインタフェース( Small Interfaces )  明示的なインタフェース( Explicit Interface )  情報隠蔽( Information Hiding )
  15. 15. 2011/2/16 直接的な写像  ソフトウェアによって提供される解決手法の 構造とモデルとして表現される問題の構造と の間のマッピングは明快な方が良い.  「連続性」と「分解のしやすさ」の基準から 導かれる. ソフトウェアシステムの構築過程で考案されたモ ジュール構造は,それに先立つ問題領域のモデル 化の過程で考案された任意のモジュール構造との 互換性を維持していなければならない.
  16. 16. 2011/2/16 少ないインタフェース  手続き,データ構造の共有を少なくする  「連続性」と「保護性」の基準から導き出さ れる すべてのモジュールができる限り少ない数のモ ジュールとの通信で済むようにすべきである.
  17. 17. 2011/2/16 小さいインタフェース  「連続性」と「保護性」の基準から導き出さ れる  不必要なデータを一緒に渡さない  悪い例:構造体を丸ごと引数に渡す⇒ × 2つのモジュールが通信する場合,そこで交信さ れる情報はできるだけ少なくすべきである.
  18. 18. 2011/2/16 明示的なインタフェース  悪い例:データ共有によるモジュール結合 A と B の 2 つのモジュールが通信するときは,必 ず,そのことが A または B あるいはその両方のテ キストから明らかに分からなければならない. データ項目 x モジュール A モジュール B 変更 アクセス
  19. 19. 2011/2/16 情報隠蔽  公開( public )属性と非公開( private )属性  モジュールの公開属性はインタフェースでもある  公開部分が少なければ,モジュールの変更の影響が 小さくて済む  機能を実装から分離する どのようなモジュールであれ,モジュールを設計 する人は,そのモジュールの属性の中からいくつ かの属性をそのモジュールに関する正式な情報と して選択し,顧客モジュールの作成者がその情報 を利用できるようにしなければならない.
  20. 20. 2011/2/16 ソフトウェア構築の5つの原則  言語としてのモジュール単位( Linguistic Modular Units )の原則  自己文書化( Self-Documentation )の原則  統一形式アクセス( Uniform Access )の原 則  開放/閉鎖( Open-Closed )の原則  単一責任選択( Single Choice )の原則
  21. 21. 2011/2/16 言語としてのモジュール単位  適切な言語を使用するべし  あるいは,言語が提供するモジュールを使っ て設計,実装すべし  例:  C 言語におけるモジュールはファイル (xxx. [ch]) ,ライブラリ  Java におけるモジュールは,クラス,パッケー ジ モジュールは仕様される言語の構文単位に対応し ていなければならない.
  22. 22. 2011/2/16 自己文書化  あるモジュールの情報を取得するのに,別に管理さ れているドキュメントを参照する必要がある⇒ ×  変更をメンテするのが大変  間違ったドキュメントよりはドキュメントが無いほうがま し  ヘッダファイルを見れば,モジュールの仕様が理解 できる⇒◎ モジュールを設計する人は,モジュールについて のすべての情報をそのモジュールの一部として作 るようにあらゆる努力をすべきである.
  23. 23. 2011/2/16 統一形式アクセス  Ruby や C# はサポートしている あるモジュールによって提供されるサービスはす べて統一された表記によって利用できなければな らない.その表記はサービスが記憶領域によって 実装されるか計算によって実装されるかにかかわ らず一定でなければならない.
  24. 24. 2011/2/16 銀行口座の2つの表現  残高フィールドを設ける  残高をその都度計算する  空間と時間のトレードオフ balance withdrawals_list depsits_list withdrawals_list depsits_list
  25. 25. 2011/2/16 閉鎖/開放の原則  モジュールが拡張を受け入れられる状態にあ る場合,そのモジュールは開放されている.  モジュールがほかのモジュールから使用でき る状態にある場合,そのモジュールは閉鎖さ れている. モジュールは開いていると同時に閉じているべき である.
  26. 26. 2011/2/16 典型的なシナリオ  古い状況  新しい状況 モジュール A モジュール C モジュール E モジュール D モジュール B モジュール ’A モジュール H モジュール I モジュール F モジュール G 継承
  27. 27. 2011/2/16 単一責任選択  選択肢の内容を1つのモジュールに閉じ込め ることで,将来の変更に備えることができる  多相性,動的束縛によって解決することが可 能 ソフトウェアシステムが選択肢を提供しなければ ならないとき,そのシステムの中の 1 つのモ ジュールだけがその選択肢のすべてを把握すべき である.
  28. 28. 悪い例 Publication p; … switch (p.type) { case BOOK: … //  何かする case JOURNAL: … // case PROCEEDINGS: … … } 2011/2/16
  29. 29. 次回予定  日時:2011年2月21日(月)10:3 0~  場所: LB  2 F / A 会議室  内容:再利用の方法 2011/2/9 オブジェクト指向プログラミング入門 1 29

×