オープンソースこねこね

Webプログラミングなどについてあれこれ。

pecoでカレントディレクトリごとによく使うコマンドを呼び出せるようにする

peco

pecoをランチャーのようにして使う

の続き。ちょいちょいスクリプトをカスタマイズしていたので。

ところで最近の開発はコードを書いているときだいたい開発中アプリケーションのトップディレクトリにいて、そこでいつもいくつか決まったコマンドを実行する、ということがよくあります。gruntとかcomposer installとかphp vendor/bin/phpunitとか。

私はPHPをよく書くのでcomposer installなどは手に馴染んでいて入力するのに困ったりしないのですが、たまにRubyのプロジェクトをいじるときBundlerの使い方を忘れていてbundle install --path=vendor/bundle --binstubs=vendor/binとかを毎回、Gistにメモっておいたスニペットから引っ張ってきて入力してたりしました。

アプリケーションごとのスニペットファイル

そこでpecoをランチャーのようにして使うで書いたスクリプトをちょっと拡張して、カレントディレクトリに.snippetsファイルをおいておくと、そこからもスニペットを取得するようにしました。

# snippets
function peco-snippets() {

    local line
    local snippet
    local cwd
    local local_snippet
    if [ ! -e "~/.snippets" ]; then
        echo "~/.snippets is not found." >&2
        return 1
    fi

    # Get snippets in the current directory if it exists.
    cwd=`pwd`
    if [ -e "$cwd/.snippets" ]; then
      local_snippet="$cwd/.snippets"
    else
      local_snippet=""
    fi

    line=$(cat $local_snippet ~/.snippets | grep -v "^\s*#" | grep -v '^\s*$' | peco --query "$LBUFFER")
    if [ -z "$line" ]; then
        return 1
    fi
    
    snippet=$(echo "$line" | sed "s/^[ |\*]*\[[^]]*\] *//g")
    if [ -z "$snippet" ]; then
        return 1
    fi

    BUFFER="$snippet"
    zle clear-screen
}
zle -N peco-snippets
bindkey '^x^x' peco-snippets

忘れやすいコマンドなどは.snippetsファイルを以下のように記述しておけば、

EArray (https://github.com/kohkimakimoto/EArray)
 * [phpunit test] php vendor/bin/phpunit
 * [fix code] php vendor/bin/php-cs-fixer fix src
 * [composer] composer update

cmd-x+cmd-xのショートカットでpecoの選択インターフェースが起動して、アプリごとに必要なコマンドが選択肢に表示されるので、あとはそこから選べばよくなりました。

f:id:kohkimakimoto:20140727114321g:plain

pecoをランチャーのようにして使う

peco shell

前回に引き続き、pecoが大変気に入ったので、その後もいろいろネットで情報さがしたりしてました。それで

peco/percolでCUIなスニペットツールを作ってみる

の記事を見て同じこと導入してみました。いやはや便利。元記事に感謝。ついでに多少カスタマイズして、スニペットの先頭にラベルをつけてみました。

手順

zshの場合は以下のような関数を.zshrcなどに記述しておく

function peco-snippets() {

    local line
    local snippet

    if [ ! -e ~/.snippets ]; then
        echo "~/.snippets is not found." >&2
        return 1
    fi

    line=$(grep -v "^#" ~/.snippets | peco --query "$LBUFFER")
    if [ -z "$line" ]; then
        return 1
    fi
    
    snippet=$(echo "$line" | sed "s/^\[[^]]*\] *//g")
    if [ -z "$snippet" ]; then
        return 1
    fi

    BUFFER=$snippet
    zle clear-screen
}

zle -N peco-snippets
bindkey '^x^x' peco-snippets

bashの場合は以下のような関数を.bashrcなどに記述

function peco-snippets() {

    local line
    local snippet

    if [ ! -e ~/.snippets ]; then
        echo "~/.snippets is not found." >&2
        return 1
    fi

    line=$(grep -v "^#" ~/.snippets | peco --query "$READLINE_LINE")
    if [ -z "$line" ]; then
        return 1
    fi
    
    snippet=$(echo "$line" | sed "s/^\[[^]]*\] *//g")
    if [ -z "$snippet" ]; then
        return 1
    fi
    READLINE_LINE="$snippet"
    READLINE_POINT=${#READLINE_LINE}
    clear
}

bind -x '"\C-x\C-x":peco-snippets'

あとはスニペットファイル.snippetに[***]の形式でラベルをつけたコマンドを記述しておく。

# SSH
[ローカル仮想環境へSSH接続:local-server01:connect] ssh kohkimakimoto@192.168.56.21 -p 22

# Vagrant
[ローカル仮想環境Vagrant状態確認:status] cd /Users/kohkimakimoto/Documents/vagrant/hk && vagrant status && cd -
[ローカル仮想環境Vagrant起動:up] cd /Users/kohkimakimoto/Documents/vagrant/hk && vagrant up && cd -
[ローカル仮想環境Vagrant停止:halt] cd /Users/kohkimakimoto/Documents/vagrant/hk && vagrant halt && cd -

# etc
[Snippetsファイルを開く:open] subl ~/.snippets
[Shell拡張設定ファイルを開く:open] subl ~/.shell_extention

2014/06/30編集

.snippetsを読みに行く前にファイルの存在チェックをいれました。

2014/07/01編集

コマンド内に[]があるとラベル削除がうまくいかないところを直しました。

pecoでコマンドラインからファイルやディレクトリを開いたりしてみる

peco shell

すこし乗り遅れた感じですが、最近話題のpecoをさわってみました。 pecoがなんなのかは以下のページなどを参照してください。

このツールはGoで書かれていて、しかも各種プラットフォーム向けにバイナリファイルを配布しているので、パスの通ったディレクトリにそのバイナリファイルをおくだけで動作するという手軽さがいいです。導入が楽なのは個人的にすごく重要なので。

機能をざっくりいうと、コマンド標準出力の行に対して選択機能のインターフェースを差し込めるというモノです。 文字にすると簡素なものですが、使ってみるとものすごく応用性の高いツールです。これホントすげー。でもこのすごさが言葉で説明できん。ツール自体のシンプルさとそれ故の応用性の高さが見事で、なんというか美しいのです。たぶんあれだ、確かUnixの哲学に「パイプやリダイレクトでつなげられるように、プログラムは最小の単位で設計すべし」みたいなものがあったハズで、それをドンピシャで体現しているんじゃないかと。pecoはpercolという同様のツールをもとに作られているとのことですが、この仕組みを考えた人は相当頭いいなーと、思わせてくれる逸品です。

さて、調べてみたらみんな自分の目的にあわせて、いろいろラッパーの関数やエイリアスを書いたりしてるみたいなので、私もちょこっと書いてみました。なおMacの環境用です。

function peco-cd()
{
    local var
    local dir
    if [ ! -t 0 ]; then
    var=$(cat -)
    dir=$(echo -n $var | peco)
    else
        return 1
    fi

    if [ -d "$dir" ]; then
        cd "$dir"
    else
        echo "'$dir' was not directory." >&2
        return 1
    fi
}

これはcdで移動したいディレクトリをfindコマンドなどで検索して、検索結果からpecoで選択、移動する、というのをやります。以下のように使っています。

find . | peco-cd

同様にfindコマンドで探したファイルを開くような関数も書きました。

function peco-open()
{
    local var
    local file
    local command="open"
    if [ ! -t 0 ]; then
        var=$(cat -)
        file=$(echo -n $var | peco)
    else
        return 1
    fi

    if [ -n "$1" ]; then
      command="$1"
    fi

    if [ -e "$file" ]; then
        eval "$command $file"
    else
        echo "Could not open '$file'." >&2
        return 1
    fi
}

これは

find . | peco-open

のように使います。またpeco-openの第二引数にコマンドを指定すれば、そのコマンドで選択したファイルを開きます。 たとえば、テキストファイルをコマンドラインで検索して、SublimeTextで開くには以下のようにやります。

find . | peco-open subl

これでもはや、Finderでちまちまディレクトリをおりていく必要はなくなったのでした。(^O^)

Bashスクリプトで実行ファイルのディレクトリを取得する

tips

よくやるのが以下の記述だったのだけれど

SCRIPT_DIR=$(cd $(dirname $0); pwd)

これだと、このスクリプトをシンボリックリンクから呼び出したときに、 実ファイルのパスでなくリンク先のディレクトリが取得されてしまっていた。 シンボリックリンクから呼び出されたときも、実ファイルのパスを返すようにするには、

SCRIPT_DIR=$(cd $(dirname $(readlink $0 || echo $0));pwd)

のようにすればよさげ。

追記)id:ngyukiさんにご指摘をいただいたので修正。

スクリプトがシンボリックリンクなディレクトリにあることを考慮して readlink -f とか cd -P とか pwd -P とかにするとなお良いのかな

おお、なるほど。やってみたら確かにシンボリックリンクなディレクトリにあるとうまくいかなかった。なので修正した以下の書き方がベターです。

SCRIPT_DIR=$(cd $(dirname $(readlink -f $0 || echo $0));pwd -P)

これならうまくいきました。

追記)2014-06-25

上記の記事はシンボリックリンクが相対パスだとやっぱりうまくいかなかったり、readlink -fがmacでは使えなかったりでいろいろ至らない。 その後もいろいろ調べたら、rbenvのスクリプト内にあったabs_dirnameがいい感じでした。 ちょこっと手直ししたのが以下になります。

abs_dirname() {
  local cwd="$(pwd)"
  local path="$1"

  while [ -n "$path" ]; do
    cd "${path%/*}"
    local name="${path##*/}"
    path="$(readlink "$name" || true)"
  done

  pwd -P
  cd "$cwd"
}

script_dir="$(abs_dirname "$0")"

枠だけのUIButtonをハイライトで背景色を変えるための拡張

ios objective-c

中身透明で枠だけのボタンを作って、ハイライト時に背景色をボーダー色と同じに変えるUIButton拡張クラス(iOS7のロック画面パスコード入力ページの数値ボタンのようなヤツね)の作り方をメモしておきます。

UIBorderOnlyButton.h

#import <UIKit/UIKit.h>

@interface UIBorderOnlyButton : UIButton

@property (strong, nonatomic, readonly) UIColor *originalBackgroundColor;

@end

UIBorderOnlyButton.m

#import "UIBorderOnlyButton.h"

@implementation UIBorderOnlyButton

- (void)setHighlighted:(BOOL)highlighted
{
    [super setHighlighted:highlighted];
    if (highlighted) {
        super.backgroundColor = [UIColor colorWithCGColor:self.layer.borderColor];
    } else {
        super.backgroundColor = self.originalBackgroundColor;
    }
}

- (void)setBackgroundColor:(UIColor *)backgroundColor
{
    [super setBackgroundColor:backgroundColor];
    _originalBackgroundColor = backgroundColor;
}

@end

setHighlightedをオーバーライドして同時に背景色を変え、元々の背景色をoriginalBackgroundColorプロパティに退避しておく しくみになっている。

あとは、IBビルダーで配置したButtonのclassをUIBorderOnlyButtonに変えて、ViewControllerなどのコード上で以下のようにボーダーを設定してやればOKです。

 self.hogeButton.layer.borderColor = [UIColor colorWithRed:1.0 green:1.0 blue:1.0 alpha:1.0].CGColor;
 self.hogeButton.layer.borderWidth = 1.0;

参考サイト:

第77回PHP勉強会でAltaxをとりあげていだだきました

PHP

4/28にEngineYardさんで行われた第77回PHP勉強会で、私がオープンソースで作っているAltaxというPHPデプロイツールをとりあげていただきました。とっても嬉しかったのでブログに書いちゃいます。PHP勉強会についての詳細はリンク先を参照ください。

第77回PHP勉強会が開催されました

セッションの内容が動画でアップされてあったので先日拝見させていただきました。 登壇者の木村さんには丁寧な資料を作っていただき、デモまでして頂いて感謝の限りです。

第77回 PHP勉強会で発表してきました : ぐりぺん

自分が作っているプログラムが衆人の前で実行される場面を見るというのは、なんだか緊張と気恥ずかしさみたいなものがあって、動画を再生しているPCの前でニヤニヤ、もじもじしてしまいました。俺きめぇ。

さて、セッション内であがっていた話題などについて、いくつか言及させていただきたいと思います。

利用実績について

Altaxの利用実績があるのかという質問に対して、登壇者の木村さんも「......う〜ん（笑」と苦笑いしておりましたが、私も聞いたことがありません（笑。ごめんなさい。 あ、でも「作者は使っているハズ」という件について、はYESと答えられます。 私自身は自分が仕事で開発、運用しているWebアプリケーションのデプロイに使っています。 使い方はデプロイ用の作業サーバがあってそこでAltaxを実行してます。処理としては

という一連の作業を自動化しています。

Githubで公開しているライブラリについて

セッション中、私がGithubで公開している他のPHPライブラリについても取り上げていただきました。 いくつか概要と私個人の利用内容について記載します。

kohkimakimoto/BackgroundProcess

これはPHPのWebアプリから非同期にコマンドを実行させるためのライブラリで、ここ にも書いたように、CSVファイルなどから一括で大量データをDBに投入するコマンドとWebインターフェースの連携に実際に使っています。 実はエラー処理まわりが不十分でその辺を修正してアップデートさせたいと思っているのですが、手がまわっていません。

kohkimakimoto/phpmigrate

MySQL用のDBマイグレーションツールです。PHPファイル一つで動くシンプルなツールで、後継のライブラリにkohkimakimoto/lib-migrationがあります。こちらはcomposerからのインストールに対応しています。 両方ともPHPクラス内に記述した素のSQLでスキーマ変更を行います。 これらのツールはこれまで素のSQLファイルと手作業でDB変更を行ってきていた古い既存システムがあって、そこにDBマイグレーションを導入する際に作ったという経緯があります。そのため今までのSQLをそのまま使いたかったのと、スキーマ定義をあまり抽象化した記述で行いたくなかったので、こういう設計のツールになりました。詳しくはここに書いてあります。

システムメンテの改善と小さなツール

Altaxもそうなのですが、これらのツールは私が実際に仕事で関わっている「3、4年まえからメンテし続けているちょっと古いシステム」の運用を改善するために作ったものです。このようなシステムは「まるっとすべてのリプレースを要するほど非効率な状態にあるわけでもないが、モダンなフレームワークなどにはある便利機能がなくて不満」という状況にあります。そこを少しずつ埋めるために開発しました。

おわりに

Altaxにはなぜか海外の開発者が多くGithubのスターをつけてくれていて、たまーにプルリクエストをくれるのも海外の方が多いです。うまく書けている自信は全然ないのですが英語でドキュメントを書いていたのがよかったのかもしれない、と個人的には思っています。 Altaxの初期バージョンはOSのSSHコマンドをPHPプログラムから実行するただのラッパーでした。改めてこれまでの開発を見直すと、なかなか成長したなあと思え、ちょっと感慨深いです。

今回、PHP勉強会で取り上げられたことはまったく予期していなかったので本当に驚いて、そしてこのように自分の作っているソフトウェアに好意的な反応をいただけるのはとても嬉しいことだな、と思いました。

コード上の利便性からオブジェクト指向を考える

オブジェクト指向 PHP

今回はオブジェクト指向について書きたいと思います。 私がオブジェクト指向を初めて学んだのは8年くらい前で、そのときはJavaでコードを書いていました。 クラス、オブジェクト、継承、ポリモーフィズムなどは 「個々の犬オブジェクト(ポチ、シロとか)があって、それは犬クラスから生成されて、犬クラスと猫クラスは、 ほ乳類クラスを継承していて両方とも鳴くメソッドを持っていて、犬はワンとなくけど、猫はニャンとなく」とか本で説明されていたのを読んで 「これがオブジェクト指向か！ なるほど（キリッ」 とか理解した気になって、おかしなコード書いて 「あれ？　やっぱオレよくわかってなくね？」 とか思ったものです。

そして間違ったコードをその後も幾度となく書いて何度も書き直して試行錯誤して、 改めて本を読み直したりして、今現在なんとかわかった気になっています。 よいコードと悪いコードをいっぱい書いてきて頭の中で知識が整理されてからだと、 前述のような犬の比喩や抽象的な説明もわかるようになります。 整理された知識が理論で支えられているような、理解に安心感が得られます。

比喩や抽象的な説明はしない

この記事は以下の方針で書かれています。

  • なるべく「抽象的」「比喩的」な説明はしない。
  • コード上の「利便性」に注目する。

これはオブジェクト指向における、比喩や抽象的な話を否定するものではありません。 でもそれだけだと、理解するのがやっぱり難しいのではないかと思っています。 そこで別の視点、もっとコードよりで結局オブジェクト指向って何が便利なの？という視点から 解説してみてはどうかなと思って書いてみました。 何はともあれ、オブジェクト指向がプログラミングで使われているのは、それが便利なのだからです。

なお、説明のためのサンプルコードはPHPを使うものとします。では始めましょう。

クラス - 関数をまとめる

クラスはオブジェクトを生成するひな形、インスタンスの設計図などと説明されることが多いですが、 ここではそのような側面は取り上げません。まず理解すべきことは以下の性質です。

クラスは関連する処理（関数）をまとめる

たとえば文字列に関する関数を以下のようにまとめておくことができます。

// 文字列関連の関数をまとめたクラス
class StringUtils
{
    // 空白文字を削除する
    public function removeBlank($str)
    {
        return str_replace(array(" ", "\t", "\n", "\r"), $str);
    }

    // 先頭n文字を切り出す
    public function head($str)
    {
        return substr($str, 0, $n);
    }
}

// 以下のように使う
$strutils = new StringUtils();
$str1 = $strutils->removeBlank("あ い うえお");
$str2 = $strutils->head("あいうえお", 2);

関連する処理、種類が同じ処理はまとまって記述してあった方が、コードが理解しやすいですよね。 これがクラスの「利便性」です。クラス内に定義した関数をメソッドと呼びます。これは名前が変わっただけです。 ただのクラス内でまとめられた関数でしかありません。

これをオブジェクト指向を使わないで書くと以下のようになります。

// string_utils.php

// 空白文字を削除する
function removeBlank($str)
{
    return str_replace(array(" ", "\t", "\n", "\r"), $str);
}

// 先頭n文字を切り出す
function head($str, $n)
{
    return substr($str, 0, $n);
}

$str1 = removeBlank("あ い うえお");
$str2 = head("あいうえお", 2);

ただ関数を一つのファイルに並べただけです。クラスにまとめたときとあまり変わらないですか？ むしろオブジェクト指向なコードはnew StringUtils()とかやっていて手間が増えていて解りづらいような。。。 そもそもnewって何をやってるんですかね。すぐにわかります。でも、今は先に進みましょう。

クラス - 変数をまとめる

クラスは関数をまとめておけると述べました。同様に関連する変数（データ）もまとめられます。

// 「人」クラス
class Person
{
    public $name;

    public $height;

    public $weight;
}

これは人を表すクラスですが、名前($name)、身長($height)、体重($weight)と人に関する変数をまとめています。 ちなみにクラスにまとめられた変数をプロパティといいますが、これも名前が変わっただけです。 変数をまとめると何が便利なんでしょうか？ 関数をまとめた時と同様にコードが理解しやすくなります。 まず$name変数が格納しているデータが人の名前であること（何かほかの動物の名前などではなく）がコード上でもはっきりわかります。 また、このプログラムが扱う「人」のデータの内容がクラス内にリストアップされていて、わかりやすいです。 それに、データを一つにまとめることで関数の引数にデータを渡すときも一回ですみます。

// クラスでまとめられた変数に値を代入
$v = new Person();
$v->name = "鈴木";  // name変数に代入
$v->height = 173;    // height変数に代入
$v->weight = 60;     // weight変数に代入

// ユーザのデータを(DBなどに)保存する処理。
// いちいち名前と身長、体重を別々に渡す必要がないので見やすい！
save_person($v);

変数$vはvalueの略でこの場合意味はありません。->はクラスでまとめた変数、関数にアクセスするための記号です。 ところで、また出てきたこのnewは何でしょう？

インスタンス - データ構造にあわせた入れ物を作る

PHPのドキュメントには以下のように書かれています。

あるクラスのインスタンスを生成するには、new キーワードを使わなければなりません。

newはクラスのインスタンスを生成しているらしいです。 クラスのインスタンス(以下単にインスタンス)とはなんでしょうか？

先ほどクラスは「変数をまとめる」と書きました。これをもうちょっと掘り下げて言い換えましょう。 クラスは変数をまとめて新しいデータ構造を作ります。 データ構造はデータ型ともよばれます。 ここでのポイントはクラスはデータそのものではなく、データの構造を作っているという点です。 例示しましょう。データ構造の例としては配列がいいです。 以下はPHPが最初から用意している配列型データ構造とそれにデータを代入している例です。

// 配列型データ構造
$v = array();
$v[0] = "aaa";
$v[1] = "bbb";
$v[2] = "ccc";

配列は複数のデータを順番にならべて格納できるデータ構造ですね。 上記のコードでは$v = array();で空の配列で変数を作っています。その後実際のデータaaa,bbb,cccをその構造にそって代入しています。

さて、前述のPersonクラスのコードを再掲してみましょう。ちょっと配列と操作が似てませんか？

// クラスのインスタンス化
$v = new Person();
$v->name = "鈴木";
$v->height = 173;
$V->weight = 60;

配列の場合もクラスの場合も、やっていることは

  • 指定したデータ構造の変数をつくる。
  • 変数の構造にあわせてデータを入れる。

ということをやっています。前述したデータに関する言葉をそれぞれのコードに当てはめてみましょう。

  • データ構造:
    • 配列の例:PHPが用意している配列という仕組み。
    • クラスの例:プログラマが定義したPersonクラス。
  • データそのもの:
    • 配列の例:$vに代入されているaaa,bbb,ccc
    • クラスの例:$vに代入されている鈴木,173,60

インスタンスとはクラスという新しいデータ構造から作られたデータの入れ物なのです。

オブジェクト

「オブジェクト指向」の「オブジェクト」について語るときがきました。 まず、言葉としてオブジェクトとインスタンスは基本的に同議です。おなじものなのです。 文脈によってインスタンスといわれることが多かったり、オブジェクトといわれることが多かったりしますが、 ほとんどの場合どっちを使ってもいいです。 例えば前述のnewキーワードの説明の

あるクラスのインスタンスを生成するには、new キーワードを使わなければなりません。

は

あるクラスのオブジェクトを生成するには、new キーワードを使わなければなりません。

でも全く問題なく、意味が通じます。それでは先に進みましょう。

オブジェクト - データと関数をまとめる

ここまでクラスの利便性を二つ述べました。

  • 関数をまとめられる
  • 変数をまとめて新しいデータ構造を作れる

実はこの二つの利便性は組み合わせることで真価を発揮します。以下にコードを例示します。

// 「人」クラス
class Person
{
    public $name;

    public $height;

    public $weight;

    // 身長、体重からBMIを計算する処理
    public function calcurateBmi()
    {
        return ($this->weight / ($this->height / 100 * $this->height / 100));
    }
}

// 以下のように使う
$v = new Person();
$v->name = "鈴木";
$v->height = 173;
$V->weight = 60;
// BMIを計算して表示する
echo $v->calcurateBmi();

これは身長$heightと体重$weight変数からBMIを計算しています。 これの利便性はやっぱりまとまっていると理解しやすいということです。 またcalcurateBmiメソッドが必要とするデータ（身長と体重）は同じクラス内にまとめられてあるので、 処理を呼び出す際データを間違えることがありません。

比較のために同じことをオブジェクト指向を使わずに書いてみましょう。

// 身長、体重からBMIを計算する処理
function calcuratePersonBmi($weight, $height)
{
    return ($weight / ($height / 100 * $height / 100));
}

$personName = "鈴木";
$personHeight = 173;
$personWeight = 60;

// BMIを計算して表示する
echo calcuratePersonBmi($personWeight, $personHeight);

calcuratePersonBmi関数に注目しましょう。 オブジェクト指向で書いたときは、オブジェクトが内部に保持しているデータを使って計算処理をしています。 一方オブジェクト指向でない(手続き型といいます)ときは、データは引数で関数の外側から渡されています。

たいした違いではありませんか？ しかしcalcuratePersonBmiの実行するとき、プログラマが引数の正しい順番(体重、身長の順)を意識して関数を呼び出さなければなりません。 それよりもあらかじめ、体重、身長をまとめたデータ構造のオブジェクトを作っておいて、あとは単純に calcurateBmiメソッドを引数なしで呼び出した方がちょっぴりシンプルで、間違えにくいと思いませんか？ これは非常に単純な例で、些細な比較ですが、オブジェクト指向プログラミングの重要な性質が現れています。つまり

データと処理をまとめることで、処理の呼び出し部分をちょっとシンプルにできる

ということです。この「呼び出し部分」はAPIなどとも言われます。 APIがシンプルであれば処理の内容が理解がしやすく、ほかのプログラムからもこれが使いやすくなります。

カプセル化

オブジェクト指向の利便性をもっと高めるため「制約」の話をしましょう。 「制約」は何かを制限するという意味の言葉なので「利便性」とは逆の概念に思えますが、プログラミングの世界では「制約」はよい影響をもたらすためによく使われます。

「人」クラスで例示してみましょう。

// 「人」クラス
class Person
{
    protected $name;

    protected $height;

    protected $weight;

    public function __construct($name, $height, $weight)
    {
        $this->name = $name;
        $this->height = $height;
        $this->weight = $weight;
    }

    // 身長、体重からBMIを計算する処理
    public function calcurateBmi()
    {
        return ($this->weight / ($this->height / 100 * $this->height / 100));
    }
}

// 以下のように使う
$v = new Person("鈴木", 173, 60);
// BMIを計算して表示する
echo $v->calcurateBmi();

前回までと変わったところは、プロパティの属性がpublicからprotectedに変更され、__constructメソッドが追加された点です。

protectedから説明しましょう。これはオブジェクトのプロパティへのアクセスを外部から禁止します。 つまり以下のようなコードが書けなくなります。

$v = new Person();
$v->name = "鈴木"; // これはエラーになる。->でプロパティにアクセスできなくなる。

__constructはコンストラクタとよばれるメソッドで、newによるオブジェクト生成時に呼び出され オブジェクトの初期処理を行います。上記の例では引数で渡した$name,$height,$weight でプロパティに初期値を設定しています。 あわせるとこのクラス（正確にはそこから生成されたオブジェクト）には

プロパティの内容はオブジェクト生成時に設定され、以後変えることができない

という制約がつけられます。このような制約をカプセル化と呼びます。これの何が便利なのでしょうか？

間違いを予防できるというのが答えです。間違ってデータを変更、削除してしまうのをさけられます。 最初に設定したら変えることができないのだから当然ですね。

Personクラスの例でいうとcalcurateBmiメソッドが正常に動作するにはプロパティの身長$height、体重$weightが設定されている必要があります。 自由にプロパティの変更ができてしまうと、これらのプロパティに値が入ってないという状況が発生してしまうかもしれません。 しかしprotected属性でアクセスを制限しているので、コンストラクタで初期値を確実に入れさえすればその後、変更、削除されることはなくcalcurateBmiは間違いなく動くということが保証されます。

プログラミングにおいて間違いをおこさせない仕組みで作るというのは設計上の基本戦略です。

ついでにもうちょっと、Personクラスを拡張してみましょう。

// 「人」クラス
class Person
{
    protected $name;

    protected $height;

    protected $weight;

    public function __construct($name, $height, $weight)
    {
        $this->name = $name;
        $this->height = $height;
        $this->weight = $weight;
    }

    // 身長、体重からBMIを計算する処理
    public function calcurateBmi()
    {
        return ($this->weight / ($this->height / 100 * $this->height / 100));
    }

    // 名前を取得
    public function getName()
    {
        return $this->name;
    }

    // 身長を取得
    public function getHeight()
    {
        return $this->height;
    }

    // 体重を取得
    public function getWeight()
    {
        return $this->weight;
    }
}

// 以下のように使う
$v = new Person("鈴木", 173, 60);
// 名前を表示する
echo $v->getName();

メソッドを三つ追加しました。getName、getHeight、getWeightです。 このメソッドによって人オブジェクトからそれぞれ名前、身長、体重のデータを外部から取得できるようになりました。 でも、依然データの更新、削除はprotectedによって禁止されています。 言い方をかえると変数と関数の組み合わせによって制約の一部を緩めることができるということです。

オブジェクトにどのような制約をつけるかは、あなたが実際に作るシステムの要件によります。 たとえば、人の名前を画面に表示する必要がある場合は、人オブジェクトから名前データをとってこなくてはならないので、 今回のように取得できるように制約を緩めます。

適切な設計へのポイント

オブジェクト指向の利便性を述べてきましたが、この利便性は適切に設計しなければその恩恵を受けられません。 オブジェクト指向でプログラミングする場合、従来の手続き型プログラミングの構造化に意識が行き過ぎていると設計に失敗します。 手続き型プログラミングだと処理を適切な粒度に切り出し関数として実装し、その関数に必要なデータを引数で渡す、というようにデータを処理というフィルターにかけるような意識で設計します。一方オブジェクト指向の場合データを適切な粒度にまとめて、そのデータを必要とする処理をくっつけるという意識で設計します。

クラスに変数と関数をまとめるとき「本当にこの場所(=クラス)に実装するのが適切か」と考える必要があります。 あわせて制約も注意深く考えましょう。特にオブジェクト内のデータを後から書き換えられるように制約を緩めるときは注意です。 不適切な変数や関数がクラス内にまとめられているかもしれません。

今回説明していないこと

クラスメソッドやクラス変数、継承やポリモーフィズムについてはまた後日。。。書くかも。