1. PHPではじめる
オブジェクト指向
VOYAGE GROUP
田中 康一

2. 自己紹介
田中康一
株式会社 VOYAGE GROUP
子会社のFlesselで
ケータイサイト開発・運用
PHP歴11年
Twitter: @mugeso

3. アジェンダ
自己紹介
アジェンダ
オブジェクト指向とは
PHPでのオブジェクト指向
オブジェクト指向の原則・法則・格言

4. オブジェクト指向とは

5. オブジェクト
データを持っている
振る舞いを持っている

6. メッセージをやり取りする
オブジェクト オブジェクト
メッセージ
メッセージ
オブジェクト

7. Web開発現場だと
開発依頼
ディレクター PM
デザイン依頼 実装依頼
デザイナ プログラマ

8. PHPでのオブジェクト指向

9. クラス

10. 例えば
社員 クラス
山田さん 鈴木さん 佐藤さん
インスタンス

11. コード例
class Employee
{
private $_name;
public function __construct($name)
{
$this->_name = $name;
}
public function getName()
{
return $this->_name;
}
}
$yamada = new Employee(‘山田’);

12. 継承

13. 例えば
社員 継承元(親クラス)
ディレクター エンジニア デザイナ
派生(子クラス)

14. コード例
class Designer extends Employee
{
public function design()
{
// デザイン処理の実装
}
}
$designer = new Designer(‘山田’);
$designer->getName(); // Employeeで定義
$designer->design(); // Designerで定義

15. インターフェイス

16. 例えば
デザイン依頼
ディレクター デザイナ
この関係を
ディレクターが求めている事に
注目してみると

17. 例えば
デザイン依頼
ディレクター デザインできる
このように置き換える事ができます。
この「デザインできる」が
インターフェイスです。

18. 例えば
デザインできる
デザイナ デザイン会社
実装としてデザイナや
デザイン会社があります。

19. 例えば
デザイン依頼
ディレクター デザイン会社
ディレクターは「デザインできる」という
インターフェイスに基づき
デザイン会社に依頼できます

20. コード例
interface DesignerInterface
{
public function design();
}
class Designer extends Employee
implements DesignerInterface // デザイナインターフェイスを実装
{
public function design()
{
// デザイン処理の実装
}
}

21. コード例
// interface DesignerInterface
// {
// public function design();
// }
class DesignerCompany extends Company // 継承元は会社クラス
implements DesignerInterface // デザイナインターフェイスを実装
{
public function design()
{
// デザイン処理の実装
}
}

22. その他機能
多重継承
インターフェイス同士の継承
定数定義

23. トレイト

24. 例えば……
現実世界で例えるのは少し難しい

25. 例えば！
映画マトリックスでヘリコプターの操縦
方法をインストールしたような感じ。

26. 例えば
エンジニア デザイナ
エンジニアとデザイナの
技術を抜き出して

27. 例えば
エンジニア デザイナ
プログラミング
技術
エンジニアとデザイナの
技術を抜き出して

28. 例えば
エンジニア デザイナ
プログラミング デザイン
技術 技術
エンジニアとデザイナの
技術を抜き出して

29. 例えば
ハイパー
クリエーター
プログラミング法
デザイン法
再利用ができます。

30. 例えば
フリーランス
ハイパー
クリエーター
継承元が違ってもOK!

31. コード例
(トレイト定義)
trait CodingTrait
{
public function coding($design, $repository)
{
// 実装
}
}

32. コード例
(トレイトの利用)
class Engineer extends Employee
{
use CodingTrait;
}
$engineer = new Engineer(‘加藤’);
$engineer->coding($design, $repository);

33. コード例
(トレイト定義)
trait DesignTrait
{
public function design($info, $repository)
{
// 実装
}
}

34. コード例
(トレイトの利用)
class HyperCreator
{
use CodingTrait, DesignTrait;
}
$creator = new HyperCreator(‘北村’);
$creator->coding($design, $repository);
$creator->design($info, $repository);

35. もしここで
trait CodingTrait
{
public function coding($design, $repository) {/* 略 */}
public function design($info, $repository) {/* 略 */}
}
trait DesignTrait
{
public function design($info, $repository) {/* 略 */}
}

36. もしここで
trait CodingTrait
{
public function coding($design, $repository) {/* 略 */}
public function design($info, $repository) {/* 略 */}
}
trait DesignTrait
{
public function design($info, $repository) {/* 略 */}
}
メソッド名が被っていたら

37. 別名をつける
class HyperCreator
{
use CodingTrait, DesignTrait
{
CodingTrait::design insteadof designCode;
DesignTrait::design insteadof designUi;
}
}
$creator = new HyperCreator(‘北村’);
$creator->coding($design, $repository);
$creator->designCode($info, $repository);
$creator->designUi($info, $repository);

38. その他機能
メソッドの可視性の変更
トレイトを組み合わせたトレイト
トレイトのメンバーの抽象化
静的なメンバー
プロパティ

39. 名前空間

40. 例えば
人事部 開発部
部長 部長
同じ部長でも仕事が違う
区別したい

41. コード例
<?php //fileA.php
namespace Personnel;
class Boss{}
<?php //fileB.php
namespace DevelopDepartment;
class Boss{}

42. コード例
<?php // fileC.php
use DevelopmentDepart;
$hoge = new Boss(); // これは開発部部長
<?php // fileD.php
use Personnel;
$hoge = new Boss(); // これは人事部部長
$foo = new DevelopmentDepart¥Boss();

43. 原則・法則・格言

44. 注意
設計・コーディングの際に意識しましょう
必ず守らなければイケナイわけではありま
せん
理由があればこれらを破るのもアリです

45. デメテルの法則

46. ディレクター ディレクター
デザイン会社 デザイン会社
デザイナ デザイナ
契約関係 指示の流れ

47. デザイン会社で
人事異動発生！！

48. 担当デザイナが交代

49. ディレクター ディレクター
デザイン会社 デザイン会社
デザイナ デザイナ
どっちが楽ですか？

50. コーディングでは
メソッドに渡されたオブジェクトと
メンバオブジェクトのみに
メッセージを送る
１行に->は１つまで

51. 単一責任の原則
(SRP)

52. 「クラスを変更する理由は
１つ以上存在してはならない」

53. 社員
じつはこいつは大きすぎる

54. 考えられる変更理由
社員番号を持たせたい
給与を振り込めるようにしたい
人事評価をできるようにしたい
人事評価の方法を変更したい

55. 社員 給与
人事評価
変更理由を考えると
このように分割できる

56. リスコフの置換原則
(LSP)

57. 「派生型はその基本型と
置換可能でなければならない」

58. 登場人物
社員
人事 プログラマ
西野さん 北野さん

59. 西野さん 北野さん

60. 西野さん 北野さん
人事評価なんだけど

61. 西野さん 北野さん
人事評価なんだけど
え？何のことです？

62. 西野さん 北野さん
人事評価なんだけど
え？何のことです？
社員なら分かれよ・・・

63. 西野さん 北野さん
人事評価なんだけど
え？何のことです？
社員なら分かれよ・・・
社員ができる事は
プログラマもできるべき！

64. 具体的には
基本クラスのメソッドを使えなくする
派生クラスから例外をなげる
これはNG!!!

65. 開放閉鎖の原則

66. ソフトウェアの構成要素は、
拡張に対して開いていて、
修正に対して閉じていなければならない。

67. うまく出来ている例
ブラウザのプラグイン
外付けハードディスク
(パソコンのネジをあけなくても使える)

68. 依存関係逆転
の原則

69. 「上位のモジュールは下位のモジュールに依
存してはならない。どちらのモジュールも
『抽象』に依存すべきである。」
「『抽象』は実装の詳細に依存してはならな
い。実装の詳細が『抽象』に依存すべきであ
る。」

70. 事業責任者
ディレクター そのものに依存
デザイナ

71. ディレクション
事業責任者
できる
デザインできる ディレクター
デザイナ 求める能力にだけ依存

72. インターフェイス分離
の原則

73. 「クライアントに、クライアント
が利用しないメソッドへの依存を
強制してはならない。」

74. 例えば
個人
契約できる
*個人契約する
*法人契約する
株式会社
個人は法人契約は
知らなくていい

75. 例えば
個人 個人契約できる
株式会社 法人契約できる
インターフェイスを分離する

76. Tell,Don’t Ask.

77. 例えば(ask)
ディレクタ デザイナ

78. 例えば(ask)
ディレクタ デザイナ
背景は何色？

79. 例えば(ask)
ディレクタ デザイナ
背景は何色？
#348fddです

80. 例えば(ask)
ディレクタ デザイナ
背景は何色？
#348fddです
ここは何px?

81. 例えば(tell)
ディレクタ デザイナ

82. 例えば(tell)
ディレクタ デザイナ
このコンセプトで
デザインよろしく。
終わったら送って。

83. 例えば(tell)
ディレクタ デザイナ
このコンセプトで
デザインよろしく。
終わったら送って。
できました。
こちらです。

84. 後者の方が
役割分担ができている。

85. コーディングでは
getter,setterは極力使わない
getter = getHoge
setter = setHoge

86. 参考文献
http://php.net/manual/
http://www.objectmentor.com/resources/
articles/Principles_and_Patterns.pdf
http://objectclub.jp/community/memorial/
homepage3.nifty.com/masarl/article/oo-
principles.html
http://wiki.shos.info/index.php?%A1%DA
%A5%AA%A5%D6%A5%B8%A5%A7%A5%AF%A5%C8%BB
%D8%B8%FE%A1%DB%A5%AA