ObjeProg の履歴(No.4)

[ トップ ]   [ 新規 | 一覧 | 検索 | 最終更新 | ヘルプ ]

• 履歴一覧
• 差分 を表示
• 現在との差分 を表示
• ソース を表示
• ObjeProg へ行く。
  • 1 (2020-09-02 (水) 00:50:21)
  • 2 (2020-09-02 (水) 03:43:12)
  • 3 (2020-09-02 (水) 05:47:56)
  • 4 (2020-09-08 (火) 08:40:20)

---

基本概念†

• クラス(設計図) = 共通性をひとまとめにした概念（なので、実体は無い）
  • クラスになるのは日常言語で 名詞 となるもの
• インターフェース = メソッドの定義
  • メソッドになるのは日常会話で 動詞 となるもの
  • インターフェースを利用することにより、メソッドの処理内容が異なるプログラムを交換可能な作りにでき
• オブジェクト = クラスから生成された実態
• インスタンス化 = クラスからオブジェクトを生成すること

• 継承 = 親クラスの性質を受け継ぐこと
• カプセル化 = 仕事の内容を隠すこと
• ポリモーフィズム = 同一のメソッドで異なる振る舞いをすること
• クラス間の関連性
  • is-a 関係 (クラス間の継承関係) : AクラスからBクラスを派生する
  • 読み方として （public class）と（A extend B）で分解、つまり新たに作るのは B である

    public class A extends B {
    }

    • ［pros］継承は親クラスの機能をそのまま使える (子クラスは親クラスのフィールド（変数）とメソッドにアクセスできる)
    • ［cons］親クラスと子クラスの間にはインターフェースを挟むことができず、密結合な関係になる
    • ［cons］親クラスの修正の影響がダイレクトに子クラスにも及ぶ、親クラスと子クラスは一心同体
  • has-a 関係 (包含関係) : AはBを含む

    public class A {
      B b;
    }

    • [cons] 包含は継承のように親クラスの機能をそのまま利用はできない
    • [pros] 包含したクラスに処理を委譲することで機能を使う（処理を任せる）ことができる
    • [pros] 包含するのをクラスではなく包含するクラスが実装するインターフェースにすることで疎結合の作りにできる
  • インターフェースの定義
    • インターフェースにはロジックを記載せず、メソッドを定義するだけ

      interface Human
      {
        void walk();
        void eat();
        void sleep();
      }

    • メソッドの定義だけなのでロジックはインターフェースを実装したクラスに書く

      class Tanaka implements Human {
          void walk() {
              System.out.println(“時速5キロで歩く”);
          }
                   : 
                   :

オブジェクト指向設計の原則 (クラス設計で5つ、パッケージ設計で6つの計11の原則があります)†

• オープン・クローズドの原則 = 「拡張に対して開いていて、修正に対して閉じていなければならない」という原則
  • 「拡張がしやすく、拡張しても修正箇所はできるだけ少なくなるような設計にするべき」という指針

• 単一責任の原則
  • クラスを変更する理由は1つ以上存在してはならない （= クラスに変更が起こる理由は1つであるべき）
  • 役割が複数あると、その役割の数分だけ変更する理由が増えてしまうため

UML図†

• クラス図 = 抽象的な表現のクラスをその構成や相互関係を表した図
  • クラス図は水平線によって3分割され、一番上にクラス名、真ん中に形や性質などの属性（データ）、一番下に操作（振る舞い）を記述
  • 
• オブジェクト図 = クラスを実体化（インスタンス化）してオブジェクト間の関係を表した図
  • オブジェクト図はインスタンス名、クラス名、変数名、値で構成される
  • 
• 接続線 (感覚的には矢印の向きが反対に感じるが...)
  • 「AはBの一種でAクラスからBクラスを派生する」というクラス間の継承関係
    • 
  • 「A has a B.」、つまり「AはBを含む」という包含関係
    • 

java での記述†

デザインパターン（= Best Practice) ---- 全２３パターン†

• Template Methodパターン
  • 処理の内容は違っても処理の流れは一緒のような状況に適用可能
  • 親クラスで処理の流れ（アルゴリズム）を実装し、処理の流れで順次呼ばれるメソッドを抽象メソッドとして宣言します。
    • 抽象メソッドとは、定義だけでサブクラスに処理を強制的に実装させるためのメソッド
    • 親クラスで宣言した抽象メソッドの具体的な処理はサブクラスで実装
  • 親クラスに処理の流れを記したテンプレートメソッドを用意し、サブクラスにフックメソッドをオーバーライド実装する
    • テンプレートメソッドから呼ばれるメソッドをフックメソッドという
    • テンプレートメソッドからは次々にメソッドが呼ばれていく
• Stateパターン
  • ポリモーフィズムを利用するためにモノについての「状態」をクラスで表現する
  • Stateパターンを適用すると個々のクラスで状態を表現するため、分岐が消えてシンプルな作りになる

教材†

• Think it 今さら聞けない！ゼロから学ぶオブジェクト指向
• 疑い深いあなたのためのオブジェクト指向再入門

     

Site admin: munakata

PukiWiki 1.5.4 © 2001-2022 PukiWiki Development Team. Powered by PHP 8.3.6. HTML convert time: 0.003 sec.