オブジェクト指向プログラミング
OOPの三原則(人間の処理能力の限界を超える) 複雑さをなるべく軽減する!カプセル化継承ポリモーフィズム
カプセル化データと手続きのまとまり処理の抽象化:構造化プログラミング→ 順接,条件分岐,反復 , サブルーチンデータの抽象化:カプセル化
ブラックボックス化      内部の処理はわからない                    入力と出力のみ決まっていて、内部の処1+1                 理は隠   している                    ブラックボックス...
スコーププログラムの複雑さを軽減する変数への不正なアクセスを遮断できる汎用的な変数 / メソッドなどでない限りスコープは小さく
継承似たような性質を括りだして同じ種類のオブジェクトの管理(便利)単継承の限界と問題点多重継承の注意点
クラス                                            人間                              インスタンス      クラス                            ...
スーパークラス     猫             人間                                    生物 クラス             クラス                                   ク...
多重継承プログラマ クラス           俺             生物          継   クラス           クラススーパークラス          承             継             承スパゲッテ...
インターフェース, Mix-in etc.静的型言語と動的型言語における多重継承による複雑さ軽減の方法静的型言語と動的型言語で、どのようにポリモーフィズムを実現しているか
インターフェース                          (Javaのような静的言語の場合)                        設計の概要を共有できる                生物魚型&生物型            ...
Mix-in(Rubyのような動的言語の場合) 多重継承の変形型(制限付きの多重継承?) クラスの木構造は保ったまま(動的型言語では)   Duck Typingで多様性を実現
Duck Typing If it walks like a duck and quacks like a duck,                 it must be a duck.クラスの継承関係やインターフェースなどは考慮せず、どのよ...
哲学(規約 / 概念 )      Ruby on Railsの基本理念CoCConvention over Configuration. 制約より規約DRYDon’t Repeat Yourself.
Convention over Configuration 制約より規約 アプリケーションの慣例に従わない部分だけ指定 すればよい 開発者は規約にしたがってコーディングし、規約 に反するところだけ別に記述すればよい プログラムに一貫性がでてくる
DRY( Don’t Repeat Yourself )情報の重複をふせぐ考え方 ⇔OAOO(Once and Only Once)情報の引き出しに対しては寛容他のコンポーネントに対しての依存を少なくできる誤用すると密結合を生む可能性がある
Upcoming SlideShare
Loading in …5
×

Oop

508 views

Published on

0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
508
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
3
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Oop

  1. 1. オブジェクト指向プログラミング
  2. 2. OOPの三原則(人間の処理能力の限界を超える) 複雑さをなるべく軽減する!カプセル化継承ポリモーフィズム
  3. 3. カプセル化データと手続きのまとまり処理の抽象化:構造化プログラミング→ 順接,条件分岐,反復 , サブルーチンデータの抽象化:カプセル化
  4. 4. ブラックボックス化 内部の処理はわからない 入力と出力のみ決まっていて、内部の処1+1 理は隠 している ブラックボックス化することで、プログ ラム全体の見通しがよくなる 変更を必要最低限に抑えることができる 2
  5. 5. スコーププログラムの複雑さを軽減する変数への不正なアクセスを遮断できる汎用的な変数 / メソッドなどでない限りスコープは小さく
  6. 6. 継承似たような性質を括りだして同じ種類のオブジェクトの管理(便利)単継承の限界と問題点多重継承の注意点
  7. 7. クラス 人間 インスタンス クラス (=オブジェクト) name: 阿良々木暦 method : 話す method : 呼吸 namename: 八九時真宵 インスタンス method : 話す (=オブジェクト) method : 呼吸method: 呼吸method: 話す
  8. 8. スーパークラス 猫 人間 生物 クラス クラス クラス 継 承 スーパークラス name name data method : 呼吸 method : 呼吸 method : 呼吸 method : 鳴く method : 話す生物クラスだけじゃなく、他のクラスにも属してるはず
  9. 9. 多重継承プログラマ クラス 俺 生物 継 クラス クラススーパークラス 承 継 承スパゲッティ継承になる可能性がある スーパークラス 学生 福岡県民 継 継クラス クラス 承 承スーパークラス スーパークラス
  10. 10. インターフェース, Mix-in etc.静的型言語と動的型言語における多重継承による複雑さ軽減の方法静的型言語と動的型言語で、どのようにポリモーフィズムを実現しているか
  11. 11. インターフェース (Javaのような静的言語の場合) 設計の概要を共有できる 生物魚型&生物型 同じ型として扱うことができる インターフェース 人間型&生物型method : 動く(泳ぐ) method : 動くmethod : (エラ)呼吸 method : 呼吸オーバーライド して実装 コンパイル時の静的な型決定と method : 動く(歩く) 実行時の動的な型決定の両立 method : (肺)呼吸 →ポリモーフィズムの実現
  12. 12. Mix-in(Rubyのような動的言語の場合) 多重継承の変形型(制限付きの多重継承?) クラスの木構造は保ったまま(動的型言語では) Duck Typingで多様性を実現
  13. 13. Duck Typing If it walks like a duck and quacks like a duck, it must be a duck.クラスの継承関係やインターフェースなどは考慮せず、どのようなメソッドを持っているかのみに関心する型宣言などはせず、したいこと(プログラムの本質)に集中して簡潔なコードを書ける書きやすい & 読みやすい動的型言語ならではの柔軟性 , スピーディな記述
  14. 14. 哲学(規約 / 概念 ) Ruby on Railsの基本理念CoCConvention over Configuration. 制約より規約DRYDon’t Repeat Yourself.
  15. 15. Convention over Configuration 制約より規約 アプリケーションの慣例に従わない部分だけ指定 すればよい 開発者は規約にしたがってコーディングし、規約 に反するところだけ別に記述すればよい プログラムに一貫性がでてくる
  16. 16. DRY( Don’t Repeat Yourself )情報の重複をふせぐ考え方 ⇔OAOO(Once and Only Once)情報の引き出しに対しては寛容他のコンポーネントに対しての依存を少なくできる誤用すると密結合を生む可能性がある

×