SlideShare a Scribd company logo
分からなそうで分かんない
オブジェクト指向
注意事項:
講義用の資料じゃないので
プレゼン目的で利用するには字が小さいです。
発表のラインナップ
1
オブジェクト指向とは何ぞや
先輩が教えてくれそうで絶対に教えないオブジェクト指向について
解説します。
3
オブジェクト指向の3つの概念
オブジェクト指向の核となる3つの概念について解説します。
2
オブジェクト指向の基本知識
オブジェクト指向の説明に必要な基本用語について説明します。
オブジェクト指向には明確な説明はない
オブジェクト指向は概念であり実体はない
故に、認識は人それぞれ
オブジェクト指向の例はさまざま
明確な答えはない
ざっくり覚えとけば良い
オブジェクト指向はまさに宗教
ここからの内容は
副部長の考えるオブジェクト指向なので
他の人の意見とは違います。
オブジェクト指向の例
(たとえ話は)ないです。
見たいなら他のサイト行ってください
発表のラインナップ
1
オブジェクト指向とは何ぞや
先輩が教えてくれそうで絶対に教えないオブジェクト指向について
解説します。
3
オブジェクト指向の3つの概念
オブジェクト指向の核となる3つの概念について解説します。
2
オブジェクト指向の基本知識
オブジェクト指向の説明に必要な基本用語について説明します。
オブジェクト指向は処理の手順を書くのではない
手続き型プログラミング
多くの人が最初に触る記述法。
一連の処理の流れの手順をひたすら書いていく。
オブジェクト指向プログラミング
今日,最もポピュラーな記述法(手続き型プログラムの派生とも言える)。
このプログラムでは動作一つ一つの手順を『オブジェクト』という形で記載。
これで作成した『オブジェクト』を部品のように必要な時に呼び出して利用する。
オブジェクトを作るには設計図となるクラスが必要
クラス
これから実際に動くオブジェクト(インスタンス)の設計図のようなもの。
設計図なので実体はなく、C言語でいうところの構造体という扱い。
ただ、クラスの中には関数も入る為、関数も入る構造体という認識が出来る。
インスタンス(オブジェクトとも呼ぶ)
クラスから作られた『モノ』のこと。
クラスは『設計図』に過ぎず『実体』はないため、クラス単体では動かない。
実際に動かすにはクラスからこれを作る必要がある。
クラスを基にインスタンスを作成する事を一般的に『インスタンス化』と呼ぶ。
クラスの要素
フィールド(メンバ変数、プロパティとも呼ぶ)
クラスが持つデータ。要するに『変数』のことである。
このデータは通常の変数同様に『int』『float』などの型名を持つ。
メンバ
『フィールド』と『メソッド』の総称です。
構造体のメンバの時に使う感覚と変わらないです。
メソッド(メンバ関数とも呼ぶ)
オブジェクトの一連の処理のパッケージです。いわゆる『関数』です。
クラスはメソッドを複数持ててそれぞれ独立していています。
これを実行するとメソッド内の一連の処理が実行されます。
オブジェクト指向のイメージ図
発表のラインナップ
1
オブジェクト指向とは何ぞや
先輩が教えてくれそうで絶対に教えないオブジェクト指向について
解説します。
3
オブジェクト指向の3つの概念
オブジェクト指向の核となる3つの概念について解説します。
2
オブジェクト指向の基本知識
オブジェクト指向の説明に必要な基本用語について説明します。
3つの必須暗記事項
カプセル化
ポリモーフィズム
継承
継承はもともとのクラスを拡張する仕組み
・攻撃()
・強い剣技()
・道具()
・逃げる()
戦士
・攻撃()
・魔法攻撃()
・道具()
・逃げる()
魔法使い
・攻撃()
・雷の魔法()
・強い剣技()
・道具()
・逃げる()
勇者
・攻撃()
・魔法攻撃()
・仲間呼び()
・道具()
・逃げる()
魔王
こんな感じのクラスがN個あるとする。
継承すると…
・攻撃()
・道具()
・逃げる()
常人
・強い剣技()
戦士(常人)
・魔法攻撃()
魔法使い(常人)
・雷の魔法()
勇者(戦士)
・仲間呼び()
魔王(魔法使い)
基本行動を
ベースとして
職業固有能力を追加。
(前職の能力も使用可能)
『サブクラス』は『スーパークラス』を継承したもの
スーパークラス(親クラスとも呼ぶ)
継承もとのクラス。
これを再利用して同じコードを書かないように出来る。
サブクラス
『親クラス』を継承して作った新しいクラス。
『サブクラス』が継承できる『親クラス』は1つだけ。
また、何らかのクラスを『親クラス』とした
『サブクラス』を『親クラス』をして継承することも可能。
『再利用性』や『拡張性』の向上に『継承』は必須
再利用性
継承することにより同じコードをまとめれるので、
必要なコードの長さは短くなる。
右図なら職業のクラスが10個以上あれば、
コードの長さは数百行以上差が出てくる。
拡張性
重複したコードを書く必要がなくなる為、
『機能の追加』や『改善』とても容易になる。
右図ですべてのクラスに『見逃す』を追加する場合、
継承前はN個の職業の全てに実装する必要がある。
継承後なら『基本行動』に実装するだけで済む。
『オーバーライド』を使ってメソッドを上書き
・攻撃()
・道具()
・逃げる()
常人
・強い剣技()
戦士(常人)
・オーバーライド 攻撃()
・魔法攻撃()
魔法使い(常人)
オーバーライド
『親クラス』のメソッドを『サブクラス』で上書きすること(そのクラス上のみ適用)。
これによりメソッドの内容は全く新しいものになります。
上図で例をあげるなら『基本行動』のクラスの『攻撃』というメソッドが、
“攻撃力の2乗 ÷ 敵の守備力 のダメージを敵に与える。”
という内容だったとします。
これを『魔法使い』では“攻撃力 ÷ 敵の守備力 のダメージを敵に与え、その後MPを回復する”
とオーバーライドすると『魔法使い』の攻撃はオーバーライドした内容になります。
一方、『戦士』の攻撃はオーバーライドの影響を受けないので元々の内容のままです。
『オーバーライド』は継承の範囲を拡張する
・『オーバーライド』が出来ない場合:
継承したメソッドの内容が必要な物と一つでも異なっていた場合は
継承することは好ましくないです。
・『オーバーライド』が可能な場合:
継承したメソッドの内容が必要な物と多少異なっていても、
異なってる部分を『オーバーライド』によって上書きすることで
上記では継承することが好ましくないクラスも継承しても良くなる。
処理が定義されていないメソッド
実装を持たない
通常のクラスでは{ }内にメソッドの処理の内容が記載されるが、
Abstractメソッドでは{ }自体が書かれず、処理は存在しない。
シグネチャと戻り値の方のみを定義
シグネチャとはメソッド名、引数の型、引数の数を指します。
Abstractメソッドとは(抽象メソッドとも呼ぶ)
Abstractメソッドとは修飾子にAbstractを持つメソッドです。
(プログラミングにおける修飾子とはそのプログラムの種類を指します。Abstractはその一種です)
Abstractは以下のような特徴を持ちます。
Abstractメソッドを持つクラスの修飾子には必ずAbstract
Abstractクラスとは(抽象クラスとも呼ぶ)
Abstractクラスとは修飾子にAbstractを持つクラスです。
Abstractの修飾子はAbstractのメソッドを持っていた場合、
必ずつける必要があります。
すなわちAbstractメソッドを一つでも持っていた場合、
そのクラスはAbstractクラスとなります。
処理が定義されていないクラス
・学生 ・プログラミング()
情報システムクラス
・実験()
物質科学クラス
・ロボット作り()
知能ロボットクラス
継承
・情報システムインスタンス
・物質科学インスタンス
・知能ロボットインスタンス
インスタンス化
抽象クラス
インスタンス化
できない。
学生のあるべき
姿を持つ。
どこからでも持ってこれるメソッド
インターフェース
これは継承関係にないクラスでも利用できるメソッド。
一つのクラスに複数のインターフェースを呼び出せる。
親クラス 子クラス
継承
親クラス
イン
イン
イン
イン
いくつでも呼び出せる
インターフェース
継承関係にないクラスに機能を提供
・攻撃力分のダメージを与える。
攻撃
・GPA分のダメージを与える。
魔法攻撃
・一定確率で戦闘を終了させる。
逃げる
基本行動
インターフェース
3つの必須暗記事項
カプセル化
ポリモーフィズム
継承
ポリモーフィズム(多態性)とは
引数を受け取ったインスタンスが
クラスによって違う振る舞いをすること。
同じメソッドの動作を引数で変化
・滅龍斬(攻撃対象の種族)
戦士
アドホックポリモーフィズム(アドホック多相)
メソッドの引数によってメソッドの動作を変化させること。
この仕組みは「オーバーロード」とも呼ばれる。
・60ダメージ。
滅龍斬(ドラゴン以外の構造体)
・120ダメージ
滅龍斬(ドラゴンの構造体)
上図の例では、
攻撃対象の敵の種族を構造体として「滅龍斬」の引数にとして渡すと
その構造体の種類によって動作を区別可能(構造体は型名として扱えるので)。
特定の型を指定しない
ジェネリックポリモーフィズム(ジェネリック多相)
複数の異なる型に対して,共通の動作を提供するメソッド。
(引数は基本的には複数の型を取れない)
さきほど図の例では、
引数として入る可能性のある型が複数種類ある。
特定の型しか引数とできない場合なら
処理は入る可能性のある引数ごとに実装する必要がある。
・滅龍斬(攻撃対象の種族)
戦士
・60ダメージ。
滅龍斬(ドラゴン以外の構造体)
・120ダメージ
滅龍斬(ドラゴンの構造体)
3つの必須暗記事項
カプセル化
ポリモーフィズム
継承
カプセル化はメンバ変数を隠蔽する事
通常のプログラム カプセル化されたプログラム
メンバ変数
抽出した値
直接取得
メンバ変数
抽出した値
アクセス制限
メソッド
アクセス修飾子によってメンバ変数へのアクセスを制限
アクセス修飾子
アクセス修飾子 概要
public
すべてのクラスからアクセ
スできる
protected
現在のクラスとサブクラス
からアクセスできる
なし
現在のクラスと同じパッ
ケージのクラスからアクセ
スできる
private
現在のクラスからだけアク
セスできる
オブジェクト指向型の言語では
アクセス制限をアクセス修飾子によって行う。
やり方は
アクセス修飾子 型名 変数名;
実際に書くと次のようになる。
// Java
private String str_var = “OCC”;
クラスも修飾子によってカプセル化できる
クラスのアクセス修飾子は継承を制限
データの隠蔽によってデータを保護
カプセル化によりアクセス方法を
メソッドで指定することにより想定外の方法での
メンバ変数へのアクセスを制限することが可能。
カプセル化されたメンバ変数へのアクセスメソッドの例
// Java
private static int getter() {
return get_num;
}
例1:
メソッドの戻り値をメンバ変数にする事で
メンバ変数を直接代入することなく
必要なメンバ変数を抽出可能。
// Java
void setter(String name) {
this.frist_word = name[0];
this.name = name;
}
例2:
メソッドの引数をメンバ変数に代入したい数値にする事で
メンバ変数に直接代入することなく
メンバ変数を変更可能。
カプセル化されたメンバ変数へのアクセスメソッドの例
カプセル化の目的はデータの保護
メンバ変数
通常のプログラムだと
メンバ変数に直接アクセス可能
→無茶な値の変化も可能な為危険
カプセル化されたプログラムだと
メンバ変数にアクセスするには
あらかじめ設定されたメソッド経由
→決められたメソッドからしか
アクセスできない為安全
ご清聴ありがとうございました
(聞いたわけじゃないけど)

More Related Content

What's hot

良質なコードを高速に書くコツ
良質なコードを高速に書くコツ良質なコードを高速に書くコツ
良質なコードを高速に書くコツ
Shunji Konishi
 
SQLアンチパターン - 開発者を待ち受ける25の落とし穴 (拡大版)
SQLアンチパターン - 開発者を待ち受ける25の落とし穴 (拡大版)SQLアンチパターン - 開発者を待ち受ける25の落とし穴 (拡大版)
SQLアンチパターン - 開発者を待ち受ける25の落とし穴 (拡大版)
Takuto Wada
 
SQLアンチパターン 幻の第26章「とりあえず削除フラグ」
SQLアンチパターン 幻の第26章「とりあえず削除フラグ」SQLアンチパターン 幻の第26章「とりあえず削除フラグ」
SQLアンチパターン 幻の第26章「とりあえず削除フラグ」
Takuto Wada
 
「あなたがいま読んでいるものは文字です」~画像情報学から見た文字研究のこれから
「あなたがいま読んでいるものは文字です」~画像情報学から見た文字研究のこれから「あなたがいま読んでいるものは文字です」~画像情報学から見た文字研究のこれから
「あなたがいま読んでいるものは文字です」~画像情報学から見た文字研究のこれから
Seiichi Uchida
 
DiI/DIコンテナを一から学んでみた
DiI/DIコンテナを一から学んでみたDiI/DIコンテナを一から学んでみた
DiI/DIコンテナを一から学んでみた
tak
 
Marp Next Tips !
Marp Next Tips !Marp Next Tips !
Marp Next Tips !
Nobutada Matsubara
 
ドメインオブジェクトの見つけ方・作り方・育て方
ドメインオブジェクトの見つけ方・作り方・育て方ドメインオブジェクトの見つけ方・作り方・育て方
ドメインオブジェクトの見つけ方・作り方・育て方
増田 亨
 
REST API のコツ
REST API のコツREST API のコツ
REST API のコツ
pospome
 
データモデリング・テクニック
データモデリング・テクニックデータモデリング・テクニック
データモデリング・テクニック
Hidekatsu Izuno
 
感情の出どころを探る、一歩進んだ感情解析
感情の出どころを探る、一歩進んだ感情解析感情の出どころを探る、一歩進んだ感情解析
感情の出どころを探る、一歩進んだ感情解析
Takahiro Kubo
 
Spring Boot の Web アプリケーションを Docker に載せて AWS ECS で動かしている話
Spring Boot の Web アプリケーションを Docker に載せて AWS ECS で動かしている話Spring Boot の Web アプリケーションを Docker に載せて AWS ECS で動かしている話
Spring Boot の Web アプリケーションを Docker に載せて AWS ECS で動かしている話
JustSystems Corporation
 
Dockerfile を書くためのベストプラクティス解説編
Dockerfile を書くためのベストプラクティス解説編Dockerfile を書くためのベストプラクティス解説編
Dockerfile を書くためのベストプラクティス解説編
Masahito Zembutsu
 
Selenium WebDriver + python で E2Eテスト自動化
Selenium WebDriver + python で E2Eテスト自動化Selenium WebDriver + python で E2Eテスト自動化
Selenium WebDriver + python で E2Eテスト自動化
JustSystems Corporation
 
リーンなコードを書こう:実践的なオブジェクト指向設計
リーンなコードを書こう:実践的なオブジェクト指向設計リーンなコードを書こう:実践的なオブジェクト指向設計
リーンなコードを書こう:実践的なオブジェクト指向設計
増田 亨
 
トピックモデルの評価指標 Perplexity とは何なのか?
トピックモデルの評価指標 Perplexity とは何なのか?トピックモデルの評価指標 Perplexity とは何なのか?
トピックモデルの評価指標 Perplexity とは何なのか?
hoxo_m
 
DDDオンライン勉強会#2 「集約・境界付けられたコンテキスト」
DDDオンライン勉強会#2 「集約・境界付けられたコンテキスト」 DDDオンライン勉強会#2 「集約・境界付けられたコンテキスト」
DDDオンライン勉強会#2 「集約・境界付けられたコンテキスト」
Koichiro Matsuoka
 
トピックモデルでテキストをクラスタリングしてみた
トピックモデルでテキストをクラスタリングしてみたトピックモデルでテキストをクラスタリングしてみた
トピックモデルでテキストをクラスタリングしてみた
Hirofumi Tsuruta
 
Spring Data RESTを利用したAPIの設計と、作り直しまでの道のり
Spring Data RESTを利用したAPIの設計と、作り直しまでの道のり Spring Data RESTを利用したAPIの設計と、作り直しまでの道のり
Spring Data RESTを利用したAPIの設計と、作り直しまでの道のり
Rakuten Group, Inc.
 
実践的な設計って、なんだろう?
実践的な設計って、なんだろう?実践的な設計って、なんだろう?
実践的な設計って、なんだろう?
増田 亨
 
SQL Server のインデックス設計
SQL Server のインデックス設計SQL Server のインデックス設計
SQL Server のインデックス設計
Koji Yamada
 

What's hot (20)

良質なコードを高速に書くコツ
良質なコードを高速に書くコツ良質なコードを高速に書くコツ
良質なコードを高速に書くコツ
 
SQLアンチパターン - 開発者を待ち受ける25の落とし穴 (拡大版)
SQLアンチパターン - 開発者を待ち受ける25の落とし穴 (拡大版)SQLアンチパターン - 開発者を待ち受ける25の落とし穴 (拡大版)
SQLアンチパターン - 開発者を待ち受ける25の落とし穴 (拡大版)
 
SQLアンチパターン 幻の第26章「とりあえず削除フラグ」
SQLアンチパターン 幻の第26章「とりあえず削除フラグ」SQLアンチパターン 幻の第26章「とりあえず削除フラグ」
SQLアンチパターン 幻の第26章「とりあえず削除フラグ」
 
「あなたがいま読んでいるものは文字です」~画像情報学から見た文字研究のこれから
「あなたがいま読んでいるものは文字です」~画像情報学から見た文字研究のこれから「あなたがいま読んでいるものは文字です」~画像情報学から見た文字研究のこれから
「あなたがいま読んでいるものは文字です」~画像情報学から見た文字研究のこれから
 
DiI/DIコンテナを一から学んでみた
DiI/DIコンテナを一から学んでみたDiI/DIコンテナを一から学んでみた
DiI/DIコンテナを一から学んでみた
 
Marp Next Tips !
Marp Next Tips !Marp Next Tips !
Marp Next Tips !
 
ドメインオブジェクトの見つけ方・作り方・育て方
ドメインオブジェクトの見つけ方・作り方・育て方ドメインオブジェクトの見つけ方・作り方・育て方
ドメインオブジェクトの見つけ方・作り方・育て方
 
REST API のコツ
REST API のコツREST API のコツ
REST API のコツ
 
データモデリング・テクニック
データモデリング・テクニックデータモデリング・テクニック
データモデリング・テクニック
 
感情の出どころを探る、一歩進んだ感情解析
感情の出どころを探る、一歩進んだ感情解析感情の出どころを探る、一歩進んだ感情解析
感情の出どころを探る、一歩進んだ感情解析
 
Spring Boot の Web アプリケーションを Docker に載せて AWS ECS で動かしている話
Spring Boot の Web アプリケーションを Docker に載せて AWS ECS で動かしている話Spring Boot の Web アプリケーションを Docker に載せて AWS ECS で動かしている話
Spring Boot の Web アプリケーションを Docker に載せて AWS ECS で動かしている話
 
Dockerfile を書くためのベストプラクティス解説編
Dockerfile を書くためのベストプラクティス解説編Dockerfile を書くためのベストプラクティス解説編
Dockerfile を書くためのベストプラクティス解説編
 
Selenium WebDriver + python で E2Eテスト自動化
Selenium WebDriver + python で E2Eテスト自動化Selenium WebDriver + python で E2Eテスト自動化
Selenium WebDriver + python で E2Eテスト自動化
 
リーンなコードを書こう:実践的なオブジェクト指向設計
リーンなコードを書こう:実践的なオブジェクト指向設計リーンなコードを書こう:実践的なオブジェクト指向設計
リーンなコードを書こう:実践的なオブジェクト指向設計
 
トピックモデルの評価指標 Perplexity とは何なのか?
トピックモデルの評価指標 Perplexity とは何なのか?トピックモデルの評価指標 Perplexity とは何なのか?
トピックモデルの評価指標 Perplexity とは何なのか?
 
DDDオンライン勉強会#2 「集約・境界付けられたコンテキスト」
DDDオンライン勉強会#2 「集約・境界付けられたコンテキスト」 DDDオンライン勉強会#2 「集約・境界付けられたコンテキスト」
DDDオンライン勉強会#2 「集約・境界付けられたコンテキスト」
 
トピックモデルでテキストをクラスタリングしてみた
トピックモデルでテキストをクラスタリングしてみたトピックモデルでテキストをクラスタリングしてみた
トピックモデルでテキストをクラスタリングしてみた
 
Spring Data RESTを利用したAPIの設計と、作り直しまでの道のり
Spring Data RESTを利用したAPIの設計と、作り直しまでの道のり Spring Data RESTを利用したAPIの設計と、作り直しまでの道のり
Spring Data RESTを利用したAPIの設計と、作り直しまでの道のり
 
実践的な設計って、なんだろう?
実践的な設計って、なんだろう?実践的な設計って、なんだろう?
実践的な設計って、なんだろう?
 
SQL Server のインデックス設計
SQL Server のインデックス設計SQL Server のインデックス設計
SQL Server のインデックス設計
 

オブジェクト指向の入門資料