Email
Like
Liked ×
Save
Private Content
Embed
Loading embed code…
We have emailed the verification/download link to "".
Login to your email and click the link to download the file directly.

To request the link at a different email address, update it here. Close
Validation messages. Success message. Fail message.

Check your bulk/spam folders if you can't find our mail.
Loading

+ Follow

オブジェクト指向できていますか？

by Moriharu Ohzu on Aug 27, 2012

114K views

Accessibility

View text version

Categories

Technology

Upload Details

Uploaded via SlideShare as Adobe PDF

Usage Rights

© All Rights Reserved

File a copyright complaint

73 Embeds 17,367

http://hiroki.jp	7973
http://hpbs002	1409
http://d.hatena.ne.jp	1186
https://twitter.com	983
http://naosim.blog16.fc2.com	792
http://www.techgig.com	643
http://obc-fight.blogspot.jp	574
http://cointoss.hatenablog.com	430
https://si0.twimg.com	351
http://bobuhiro11.net	350
http://tech.shuntak.net	303
http://bikkuri.me	250
http://naosim.syoyu.net	215
http://localhost	199
https://twimg0-a.akamaihd.net	155
http://notes.shuntak.net	152
http://assaulter.hatenablog.com	143
http://otto.sytes.net	142
http://www.pochi.cc	128
http://takubon.hatenablog.com	119
http://labs.asunochikara.com	97
http://s.deeeki.com	73
http://naganegi0505.hatenablog.com	65
http://10.150.200.57	61
http://control.blog.fc2.com	53
http://twitter.com	52
http://memerelics.tumblr.com	47
http://obc-fight.blogspot.com	41
http://flavors.me	38
http://10.8.0.201	37
http://49.212.192.99	35
http://omega014.tumblr.com	30
http://pute293.tumblr.com	24
http://tweetedtimes.com	22
http://webmemo.uzuralife.com	21
http://2764315556584061984_73861a7364f94f99e40694ede4186de175c91c27.blogspot.com	19
http://b.hatena.ne.jp	16
http://otrsrv-mzp	15
http://133.242.3.32	14
http://wiki.dev.cybozu.co.jp	9
http://192.168.3.38	8
http://unkei3.tumblr.com	8
http://webcache.googleusercontent.com	7
http://fejado.blogspot.jp	6
http://favtile.com	6
http://www.twylah.com	5
http://tomoyamkung.net	5
http://a0.twimg.com	5
http://feeds.feedburner.com	4
http://pinterest.com	4
http://spiri-tua-lism.com	4

More...

Statistics

Likes: 467
Downloads: 938
Comments: 7
Embed Views: 17,367
Views on SlideShare: 96,932
Total Views: 114K

1–7 of 7 previous next Post a comment

Masaya Nasu at ジャストシステムとりあえず長い関数を分割することからはじめてみよう 9 months ago
Are you sure you want to
Moriharu Ohzu at 日本工学院八王子専門学校 takano32様、ご指摘ありがとうございます。P43修正いたしました。P46はmyFriendをリファクタリングして、getYourFriendを呼ばないようにするという意図です。 9 months ago
Are you sure you want to
takano32 P43 typo LimetTime P46 me.getYourFriend() ? -- yourFriend = me.getYourFriend(); yourFriend.method(); -- more better, i think so. 9 months ago
Are you sure you want to
Ken Masumitsu at アクセンチュアなるほどね。 9 months ago
Are you sure you want to
Tomonori Arakawa オブジェクト指向強制ギブス。これをつけた上で仕事をする、という試みとかしてみたい。 9 months ago
Are you sure you want to
Hiroshi Ueki 大圖さんのスライドにはいつも感嘆しています！７６枚目で思わず吹き出しそうになりましたが...。とても参考になりました！ 9 months ago
Are you sure you want to
Toshiyuki Uchida, Owner at リアルメディカル株式会社とてもプラスの刺激を受けました^^ ありがとうございます！ 9 months ago
Are you sure you want to

467 Likes

美貴夫若藤, 事業推進本部　プラットフォーム企画 at グリー 2 hours ago
翼吉野 1 week ago
happyyatani 2 weeks ago
Junpei Yokota at 九州大学 2 weeks ago
Hideaki Ishii 3 weeks ago
indros 3 weeks ago
takamii228 4 weeks ago
Wataru NAKAHATA 1 month ago
Yasuhiro Mutaguchi 1 month ago
Takumi Hachisu 1 month ago

オブジェクト指向できていますか？ Presentation Transcript

オブジェクト指向できていますか？真のオブジェクト指向が身に付くコーディング規約日本工学院八王子専門学校大圖衛玄
CEDEC 2012講演時のスライドです。http://cedec.cesa.or.jp/2012/program/PG/C12_P0084.html
自己紹介 1992年～1997年某ゲーム会社プログラマ SFC,GB,PS1,N64のゲーム開発経験 1998年～現在日本工学院八王子専門学校 @mozmoz1972 専任講師プログラミング教育を中心に担当twitterもfacebookも実名です。よかったらフォローしてください。
オブジェクト指向できていますか？
なぜオブジェクト指向できないのか？
手続き型の言語から学習した人がＯＯＰするには大きな発想の転換が必要です。
そのクラスは巨大な１枚岩のコードで作成され・・・（次に続く）
全ての機能が実装されていた・・・（次に続く）
人々はそのクラスを「神クラス」と呼んだ。非ＯＯＰなコードの特徴です。
Stage1 Stage2 Stage3 Stage4 Stage5実際にあった伝説のコード。シンプルな２Ｄゲームなのに１万行ありました。調べてみると、ステージごとに、まるごとコピペで作成した神クラスが５つ。１ゼウス２千行、５ゼウスで、合計１万行となっていました。
理想的なオブジェクト指向の世界とは？
小さな大量のオブジェクトが・・・（次に続く）
お互いメッセージを送りながら協調し複雑なシステムを構築する。（次に続く）
各クラスは、１つの機能に集中し、最小限のインターフェースで構成されています。
コーディング規約で理想的なオブジェクト指向の世界を目指す本セッションのゴールです。
命名規則やスペースの数、｛｝位置などのコーディング規約のお話ではありません。
オブジェクト指向エクササイズ Jeff Bayソフトウェア設計を改善する９つのステップ
第５章に書かれているJeff Bay氏によるエッセイになります。
読後の衝撃は忘れられません。理想的なオブジェクト指向の姿が理解できました。
Jeff Bayが冒頭で紹介している、７つのコード品質特性です。
Extreme必然的にオブジェクト指向になってしまう、Extremeなコーディング規約です！
メソッドにつきインデントは１段階 １つのメソッドごとに制御文を１つに制限 ｉｆ、ｆｏｒ、ｗｈｉｌｅごとにメソッド化する 制御文の内側をメソッド化する 早期リターンを活用しインデントを浅くする制御文のネストをなくすルールです。小さく、単純なメソッドを作成するのが目的です。
void Class::method() { void Class::method() { for (外側ループ) { for (外側ループ) { for (内側ループ) { for (内側ループ) { if (条件) { method1(…); 処理; } } } } } } } void Class::method1(…) { if (!条件) return; 処理; } Before After制御分の内側から順番にメソッド化していきます。
void Class::method() { void Class::method() { for (外側ループ) { for (外側ループ) for (内側ループ) { method2(…); method1(); } } } void Class::method2(…) {} for (内側ループ) method1(…); } Before After
void Class::method() { void Class::method() { for (外側ループ) { for (外側ループ) for (内側ループ) { method2(…); if (条件) { } 処理; void Class::method2(…) { } for (内側ループ) } method1(…); } } } void Class::method1(…) { if (!条件) return; 処理; } Before After制御文ごとにメソッド化され、ネストが１段階となりました。
for (int i = 0; i < 5; ++i) { if (a[i] == num) { return true; } } return false; Before return find(&a[0], &a[5], num) != &a[5]; After検索などのループは、標準の関数を利用しましょう。STLのfindに変更しました。
totalAge = 0; totalSalary = 0; for (int i = 0; i < 5; ++i) { totalAge += ages[i]; totalSalary += salarys[i]; } Before totalAge = 0; for (int i = 0; i < 5; ++i) totalAge += ages[i]; totalSalary = 0 for (int i = 0; i < 5; ++i) totalSalary += salarys[i]; Afterループの内側で２つのことを扱うと、メソッド化が困難です。ループを分割します。
totalAge = 0; for (int i = 0; i < 5; ++i) totalAge += ages[i]; totalSalary = 0; for (int i = 0; i < 5; ++i) totalSalary += salarys[i]; Before totalAge = accumulate(&ages[0], &ages[5], 0); totalSalary = accumulate(&salarys[0], &salarys[5], 0); After配列の合計はSTLのaccumulate関数で求められます。
totalAge = accumulate(&ages[0], &ages[5], 0); totalSalary = accumulate(&salarys[0], &salarys[5], 0); Before int Class::totalAge() { return accumulate(&ages[0], &ages[5], 0); } int Class::totalSalary() { return accumulate(&salarys[0], &salarys[5], 0); } Afterさらにメソッド化をしてみました。
totalAge = 0; totalSalary = 0; for (int i = 0; i < 5; ++i) { totalAge += ages[i]; totalSalary += salarys[i]; } Before int Class::totalAge() { return accumulate(&ages[0], &ages[5], 0); } int Class::totalSalary() { return accumulate(&salarys[0], &salarys[5], 0); } AfterMartin Fowlerの「Split Loop」というリファクタング例になります。
ｅｌｓｅ句を使用しないこと 早期リターンを活用する ｅｌｓｅｉｆ、ｓｗｉｔｃｈの条件分岐を避ける Ｓｔｒａｔｅｇｙ、Ｓｔａｔｅなどのデザパタを活用 三項演算子（？）を利用する条件分岐を単純化するのが目的です。
int method() { int method() { int result; if (!条件1) if (条件1) { return 10; if (条件2) { if (条件2) result = 20; return 20; } else { return 30; result = 30; } } } else { result = 10; } return result; } Before After左と右のコードは同等の処理を行います。早期リターンを使うと単純になります。
switch (actorType) { class Actor { case PLAYER: public: virtual void update() = 0; updatePlayer(); }; break; case ENEMY: updateEnemy(); actor->update(); break; case BULLET: updateBullet(); break; } Before After「State/Strategyによるタイプコードの置き換え」というリファクタリングです。
int method() { int method() { int result; return 条件 ? 20: 30; if (条件) } result = 20; else result = 30; return result; } Before After三項演算子(?)は使いすぎると、わかりにくくなりますが、単純なケースでは有用です。
if (x < 0) { x = 0; } else if (x > 640) { x = 640; } Before x = max(0, min(640, x)); After上記のようなif文は、よく見かけますが、STLのmin,max関数で書き直せます。
if (x < 0) { x = 0; } else if (x > 640) { x = 640; } Before x = clamp(x, 0, 640); float clamp(float x, float bottom, float top) { return max(bottom, min(top, x)); } Afterさらにclampという関数を作ってみます。C++であれば、関数テンプレート化しましょう。
すべてのプリミティブ型をラップ ｉｎｔ、ｆｌｏａｔなどの基本型をラップする ｓｔｒｉｎｇなども基本型の扱いとする 得点、時間などの変数をクラス化する すべての状態変数をカプセル化するすべてをオブジェクト化するのが目的です。intやfloatはオブジェクトではありません。
class Game { class Game { private: private: int score; Score score; int limitTime; LimitTime time; }; }; class Score { private: int score; }; class LimitTime { private: int time; }; Before After得点や制限時間をクラス化します。「すべてがオブジェクト」になっていきます。
１行につきドットは１つまで 直接の友人にだけ話かける 友達の友達とは関連を持たない デメテルの法則に従う余計なクラスとの結合を避けるのが目的となります。
myFriend.getYourFriend().method(); Before myFriend.method(); After「保持しているもの、引数で渡されたもの、自ら作成したもの」だけを扱います。
寿限無、寿限無五劫の擦り切れ海砂利水魚の水行末雲来末風来末食う寝る処に住む処やぶら小路の藪柑子パイポパイポパイポのシューリンガンシューリンガンのグーリンダイグーリンダイのポンポコピーのポンポコナーの長久命の長助長ったらしい名前を付けなさいという意味ではありません。その逆です！
名前を省略しない 省略したいほど長い名前がつく原因を考える 命名困難なクラスやメソッドは要注意 複数の責務を持っていると命名困難になる 名前は１つか２つの単語だけ使う名前が長くなるのは、設計に問題があるのではないか？という意図です。
void Game::updateAndDrawPlayer(Graphics& g) { playerPosition += Vector2(5.0f, 0.0f); g.drawImage(playerImage, playerPosition); } Before void Game::updatePlayer() { playerPosition += Vector2(5.0f, 0.0f); } void Game::drawPlayer(Graphics& g) { g.drawImage(playerImage, playerPosition); } After２つのことを同時にやってしまうと、名前を付けるのが難しくなります。
void Game::updatePlayer() { playerPosition += Vector2(5.0f, 0.0f); } void Game::drawPlayer(Graphics& g) { g.drawImage(playerImage, playerPosition); } Before void Game::update() { player.update(); } void Game::draw(Graphics& graphics) { player.draw(graphics); } Afterメソッドを分割し、さらにクラスの抽出を行いました。名前が単純になりました。
すべてのエンティティを小さくする ５０行を超えるクラスは作らない １０ファイルを超えるパッケージは作らない 単一の責務を持つ凝集度の高い設計とする凝集度を高めれば、クラスやパッケージは小さくできる。という意図になります。
インスタンス変数は２つまで クラスは１つの状態変数に責任を持つ ２つの変数を扱う調整役のクラスもある 状態変数が増えるたびに凝集度が低下１つの状態を管理するクラスと、２つの状態を調整する２種類のクラスが存在します。
class Player { class Player { private: private: float x; Vector2 position; float y; Angle angle; float angle; Life life; int life; }; }; class Angle { private: float angle; }; class Life { private: int life; }; Before After状態変数が２つになるまで、段階的に変更していきます。
class Player { class Player { private: private: Vector2 position; Transform pose; Angle angle; Life life; Life life; }; }; class Transform { private: Vector2 position; Angle angle; }; Before Afterpositionとangleは座標変換を扱うクラスとして、まとめられそうです。
class Player { class Player { private: private: float x; Transform pose; float y; Life life; float angle; }; int life; }; Before After状態変数が２つになりました。
class Player { class Player { public: public: Player(float x, Player(Transform& pose, float y, Life& life); float angle, void update(Time& time); int life); private: void update( Transform pose; float time); Life life; private: }; float x; float y; float angle; int life; }; Before After右側のクラスは、すべてがオブジェクトと関連しています。抽象度が高くなるわけです。
ファーストクラスコレクション ｖｅｃｔｏｒ、ｌｉｓｔなども基本型としてラップする クラスにはコレクションを１つだけ持たせる もちろん配列も対象になる汎用のコレクションクラスもプリミティブ型と同様に扱うという意図です。
class Game { private: std::list<Actor*> actors; std::list<Particles*> particles; }; Before class ActorManager { std::list<Actor*> actors; }; class ParticleManager { std::list<Particle*> particles; }; After２つのコレクションを１つのクラスで扱えば、おそらく複雑なクラスになるでしょう。
class Game { private: std::list<Actor*> actors; std::list<Particles*> particles; }; Before class Game { private: ActorManager actors; ParticleMananger particles; }; After専用のクラスを作って、そちらに委譲してしまいます。
ＧｅｔｔｅｒＳｅｔｔｅｒを使用しない ＧｅｔｔｅｒＳｅｔｔｅｒなどのアクセッサを禁止 極度のカプセル化を行う クラス外に振る舞いが漏れ出すのを防止 「求めるな、命じよ」に従うGetter/Setterを付けてしまうと、カプセル化が崩壊してしまうという意図です。
構造体すべてのメンバ変数にGetter/Setterを持たせると、単なる構造体になってしまいます。
void Game::draw(Graphics& g) { Vector2 position = player.getPosition(); Image& image = player.getImage(); g.drawImage(image, position); } Before void Game::draw(Graphics& g) { player.draw(g); } void Player::draw(Graphics& g) { g.drawImage(image, position); } AfterGetterで「求める」のではなく、オブジェクトに「命じよ」。自分のことは自分でやらせる。
void Game::update() { Vector2 position = player.getPosition(); position += Vetcor2(5.0f, 2.0f); player.setPosition(position); } Before void Game::update() { player.move(Vetcor2(5.0f, 2.0f)); } After振る舞いが外に出てしまっています。オブジェクト自身に行動させます。
振る舞いが外に出てしまうと、コードの重複を生み出す原因になります。
状態は、すべてカプセル化され、メッセージのやりとりだけで、協調して動作する。
＃１１つのメソッドにつきインデントは１段階まで＃２ｅｌｓｅ句を使用しないこと＃３すべてのプリミティブ型をラップする＃４１行につきドットは１つまで＃５名前を省略しない＃６すべてのエンティティを小さくする＃７１つのクラスにつきインスタンス変数は２つまで＃８ファーストクラスコレクションを使用する＃９ＧｅｔｔｅｒＳｅｔｔｅｒを使用しない
実際にやってみたエクササイズに挑戦した、ソースコードの解説をしました。(1000行程度のものです)
Jeff Bay挑戦した人だけが、たどり着ける高みがあるのです。
オブジェクト指向が、いったい何であるかを理解した瞬間をカメラに収めました。
エクササイズまとめ 騙されたと思って小さなプログラムで試す 今までとは異なるアプローチが必要になる すべてのルールが普遍的に適用できない ルールを緩めてガイドラインとして利用するルールには、例外も出てきます。ルールの「目的や意図」を理解することが重要です。
Jeff BayJeff Bayのエッセイの結びに書いてあった内容です。（抜粋してあります）
９つのルールに関連する、オブジェクト指向設計の原則を紹介しました。
オブジェクト指向設計の原則単一責任の原則オープン・クローズドの原則リスコフの置換原則依存関係逆転の原則インターフェース分離の原則「単一責務の原則」と「依存関係逆転の原則」の２つだけ解説します。
単一責任の原則 Single Responsibility Principles クラスを変更する理由は１つ以上存在してはならないひとつのクラスには１つの責任だけを持たせるという意味です。
凝集度凝集度とは、１つのクラスがどれだけ、１つのことに集中しているか？ということです。
f1 f1 f1 f3 f4 f1 f3 f4 f3 f4 f2 f3 f4 f2 f2状態が１つの場合、凝集度は最高に。２つでも全メソッドで使用されれば問題なし。
f1 f2 f1 f1 f1 f1 f2 f2 f2 f2凝集度が低い状態です。明らかに、２つの責務を扱っています。
f1 f2 f1 f2 f1 f2 f1 f2 f2 f1メソッドが大きいと、凝集度が低いのか、高いのか判断できません。（大抵は低いはず）
f1 f2 f1 f2 f1 f1 f1 f2 f1 f1 f2 f1 f1 f2 f2 f2 f2 f2 f1 f2状態変数の振る舞いを観察しながら、細かくメソッド化をしていきます。
f1 f1 f2 f1 f1 f1 f1 f1 f1 f1 f2 f2 f2 f2 f2 f2 f2 f2メソッドをグループ化して、クラスを抽出します。
f1 f1 f1 f1 o1 o2 o1 o2 f2 f2 f2 f2抽出後の状態です。凝集度は最高の状態になっています。
大きな関数を多くの小さな関数へ分割することが、クラスを、より小さなクラスへと分割することにつながるのです。「Clean Code 」からの引用です。メソッド化がクラス化への第１歩になります。
平均的なクラス理想的なクラス私見ですが、世の中の平均的なクラスは、大きすぎると思います。
小さな部品を組み合わせながら、複雑なシステムを構築していきます。
再利用可能なクラスとは、ネジのように単純なことを行う小さなクラスなのです。
依存関係逆転の原則 The Dependency Inversion Principles 上位のクラスは下位のクラスに依存してはならないどちらも「抽象」に依存する
疎結合オブジェクトは、協調しつつも疎結合であることが望まれます。
class Sphere { class Sphere { public: public: void draw( void draw( ID3D11Device& g); ISphereRenderer& g); private: }; Vector3 center; float radius; class ISphereRenderer { }; public: virtual void draw( Vector3 center, float radius ) = 0; }; Before After直接、実装のクラスではなく、抽象インターフェースに依存させます。
void Sphere::draw( void Sphere::draw( ID3D11Device& g) { ISphereRenderer& g) { // 頂点バッファ作成 g.draw(center, radius); // インデックスバッファ作成 } // 球体の頂点データを計算 // シェーダー作成 // 頂点レイアウト作成 // 描画コンテスト作成・・・ // なんとか描画する } Before After抽象インターフェースに依存させれば、実装の詳細に依存しなくなるわけです。
Sphere.cpp Sphere.cpp ISphereRenderer.h SphereRenderer.cpp DirectX DirectX Before After右図の青い「上向き」の矢印に注目してください。依存関係が逆転しています。
問題領域問題領域のクラス抽象インターフェース実装領域実装クラスＡＰＩ Windows API, DirectX, OpenGL問題領域と実装を分離すれば、それぞれのクラスの凝集度を高めることができます。
class ISphereRenderer { class Sphere { public: public: virtual void draw( class Renderer { Vector3 center, public: float radius) = 0; virtual void draw( }; Vector3 center, float radius) = 0; class Sphere { }; public: void draw( void draw( Renderer& g); ISphereRenderer& g); }; }; Before After抽象インターフェースをインナークラス化し完全に自己完結させた例です。（極端か？）
あなたのあなたのコードコード抽象実装レガシーコードレガシーコードレガシーコードの分離にも役立ちます。不要な複雑さを持ち込まないようしましょう。
インターフェースと実装を分離する実装そのものではなくインターフェースに対してプログラミングせよ抽象インターフェースは、多態性だけではなく、依存関係の分離の役割も果たします。
Jeff Bayの９つのルールを参考に作成した、コーディング規約の事例紹介です。
７つのコーディング規約お尻は掻いてもクソース書くな２０１２年改訂版学生対象のゲーム制作プロジェクトで実際に採用した規約です。
複雑度１０まで複雑度とは、McCabeの循環的複雑度を意味します。（ほぼ制御文+1になります）
１メソッド２０ステートメントまでステートメントとは実質的なプログラムの行数です。（コメントなどを除きます）
１クラス８０ステートメントまで
ネスト２段階まで
ｓｅｔｔｅｒ使用禁止Getterは最小限に、Setterのみ禁止にしました。
フィールド４つまで特に根拠がある数ではありません。フィールド数は、できるかぎり少なくしましょう。
tweet! ソースコードを愛せよネタです。
≒Jeff Bayのルールに比べれば、「ゆとり」仕様になっていませんか？
コーディング規約の調整理想標準妥協複雑度 5 10 15 ネスト 1 2 4 メソッド長 10 20 40 クラス長 50 80 160厳しすぎてもユルすぎてもダメです。まずは、無理なく守れる程度がよいと思います。
http://www.slideshare.net/MoriharuOhzu/ss-9224836昨年のスライドで、コーディング規約の確認の方法や順守させる工夫を紹介しました。
抽象度クラスやメソッドの行数を制限することにより、全体の抽象度を高める効果があります。
３つの極度極度の抽象化極度の分離極度の読みやすさ極度の抽象化の考え方は、上記の本でも紹介されています。
まとめ コーディング規約の本質を知ることが重要 例外もあるので、無理やり適用はしない ガイドラインとして活用するところから始める トレーニングとして研修に取り入れてみる繰り返しになりますが、ルールの「目的や意図」を理解することが重要です。
クラス設計のポイントです。
小さい単純重複なしクラス、メソッドのすべてに、このルールがあてはまります。
http://www.bennadel.com/resources/uploads/2012/ObjectCalisthenics.pdf英文になりますが、Jeff Bayのオブジェクト指向エクササイズの全文が入手可能です。
http://www.slideshare.net/yojik/ss-1033616SlideShareで紹介されている、オージス総研の方のスライドです。
http://www.slideshare.net/rdohms/your-code-sucks-lets-fix-itこちらもSlideShareのスライドです。言語はPHPですが、参考になると思います。
最近では、オブジェクト指向と関数型のハイブリッド言語が注目を浴びています。
タイプの異なる３つの言語を３人の女性に例えました。ちょっと考えてみてください。
オブジェクト指向がすべてではありません。さまざまな言語から異なる発想を学びましょう。
普通のやつらの上を行け Paul GrahamPaul Grahamのエッセイのタイトルから引用しました。
コードと共に生き続ける Moriharu Ohzu