by shigemk2

当面は技術的なことしか書かない

PHPではじめるオブジェクト指向 #phpcon2012

PHPカンファレンス 2012

オブジェクト指向とは

データを持っている
振舞いを持っている

オブジェクト同士でメッセージをやりとりする

ディレクター (開発依頼)→ PM (デザイン依頼)→デザイナ
↓(実装依頼)
プログラマ

PHPにおいて

クラス

社員クラス

山田 鈴木 佐藤 (インスタンス)

コード例

<?php

class Employee { 
  private  $_name;
  public function __construct($name) {
    $this->_name = $name;
  }
}

$yamada = new Employee('山田');

継承

社員←ディレクター エンジニア デザイナ

<?php

class Designer extends Employee { 
  public function desing() {
    // 実装
  }
}

$yamada = new Designer('山田');

インターフェイス

ディレクター (デザイン依頼)→ デザインできる

デザインできる ← デザイン + デザイン会社

<?php
interface DesignerInterface { // 必ず実装しないといけない
  public function design();
}
class DesignerCompany extends Company { // 継承元は会社クラス
  implements DesignerInterface; // デザイナインターフェイスを実装
  public function design() {
    // 実装
  }
}

$yamada = new Designer('山田');

その他機能

  • 多重継承
  • インターフェイス同士の継承 (あるインターフェイスから別のインターフェイスを継承することが出来る)
  • 定数定義

トレイト

PHP5.4から導入された機能

エンジニア(プログラミング方法) デザイナ(デザイン法)

デザイナがプログラミング方法を使うためには…

ハイパークリエイター(プログラミング方法 + デザイン法) → フリーランス

<?php
trait CodingTrait {
  function coding() {
    // 実装
  }
}

class Hoge {
  use CodingTrait, DesignTrait;
}

$creator = new Hoge();
$creator = $this->coding();
$creator = $this->design();

Traitのなかでメソッド名がかぶっていたら、insteadofで別名をつけることも出来る

その他機能

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

名前空間

人事部「部長」 vs 開発部「部長」

<?php
namespace Personnel;
class Boss{};

namespace Development;
class Boss{};

use Personnel;
$hoge = new Boss();

use Development;
$foo = new Boss(); // 違う意味を有する

原則 法則 格言

デメテルの法則

  1. ディレクター
  2. デザイン会社
  3. デザイナ

ディレクターから直接デザイナーに命令が下る場合と、デザイン会社を介して命令が下る場合がある

e.g. デザイン会社で人事異動が発生した その場合、デザイン会社を介して命令を下したほうが、
デザイン会社がよしなにやってくださるはず。

デメテルの法則 on コーディング

メソッドに渡されたオブジェクトと、メンバオブジェクトのみにメッセージを送る
1行に->は1つまでのほうがよい

単一責任の法則

クラスを変更する理由は1つ以上存在してはならない

社員というクラスは大きすぎる(社員という体を各パーツに分解する パーツをいろいろなタイプに分類する)

リスコフの置換原則

派生型は基本型と置換可能でなければならない
社員クラスから派生されたものは、社員の原則を共有しなければならない

  1. 基本クラスのメソッドを使えなくする
  2. 派生クラスから例外を投げる

解放閉鎖の原則

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

拡張はどこからでも出来るようにしないといけないが、
修正は場所が確実でないといけない

依存

依存関係はモジュールではなく、インターフェイスに依存していなければならない。

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

ひとつのインターフェイスが色々な責任を有してはいけない

Tell, Don't Ask.

メソッド実装のさいに、何かききだすようなものではなく、
命令をするような実装にしないといけない。

詳細が知りたい場合は、ぐぐれ。