投稿日:

オブジェクト指向プログラミングを理解する為の4つのポイント


一度理解してしまうと、もうそういう風にしか考えられなくなるけれど、理解するまではちょっと難しい、そんな「オブジェクト指向プログラミング」ですが、その理解に少しでも近づけるように、僕なりのポイントを4つ程挙げてみました。突っ込みどころも多いとは思いますが、僕なりの考えです。オブジェクト指向プログラミングはやってるけれど「何かあまりしっくりと来ていないな…」という方へ、ちょっとでも参考になれば幸いです。

1. クラスと継承は、忘れる

オブジェクト指向プログラミングの解説で、まず最初に「クラス」と「継承」の説明がなされることがよくあります。間違いでは無いでしょうし、多くのオブジェクト指向プログラミング言語ではクラスはとても重要な役割を担います。Java はクラスが無ければオブジェクトを作ることも出来ません。しかし、やっぱり一旦忘れてください。クラスや継承は、オブジェクト指向プログラミングを理解するにうえで、大きな誤解を生むことがあるからです。

「継承によって、あるオブジェクトが他のオブジェクトの特性を引き継ぐ」—— 継承についての説明です。しかし、これを単に「機能を効率的に(あるいは簡単に)受け継ぐ手段」だと理解してしまうことがあるようです。でもそれは間違った理解です。ここでの間違った理解は、典型的な「ごった煮クラス」を作成してしまう罠の入り口です。便利だから、便利だからと、あるクラスに山のようなメソッドが実装されていきます。そしてやがて、アプリケーションの大半のロジックが1つのクラスに実装され、まるでベタ書きの PHP のようになったコードを見た事があります。

クラスと継承は、オブジェクト指向プログラミングを理解する上では雑音になります。一旦忘れてください。

2. 包含関係は重要

継承関係と同様に大切な概念として紹介される概念に「包含関係」があります。オブジェクト指向プログラミングの解説ではよく、継承関係を「is-a関係」、包含関係を「has-a」関係と説明されます。継承は忘れてくださいと書きましたが、実はこの「包含関係」こそ、オブジェクト指向プログラムの実現する上でとても重要な概念ですので、しっかりと抑えることが大切です。

「オブジェクトが別のオブジェクトを所有し、その機能を利用する」—— これが「包含関係」です。具体例は次のパートで挙げたいと思いますが、例えば、あるオブジェクトAが幾つかの機能を持つ時、その機能の一部を別のオブジェクトBに担当させ、オブジェクトAはオブジェクトBを所有することで、オブジェクトBの機能を利用することを言います。

極端な話、継承は無くてもオブジェクト指向プログラミングは実現できますが、包含の概念はとても重要です。どういうわけか、オブジェクト指向プログラミングの多くの解説において、継承についての説明はたっぷりあるものの、包含についての説明は小さな扱いになっているような気がします。そのような中でクラスと継承を学ぶと、この包含関係の重要性についての気付きが遅れてしまいがちになります。ですので、しつこいですが、継承は一旦置いておいてください。そして包含関係について、重要だと思って注目してください。

3. オブジェクトは役割を持つ

オブジェクトはそれぞれ、何らかの役割を担います。役割は明確であることが大切です。オブジェクトはそれぞれの役割を与えられて、その与えられたその役割について責任を持つ。これこそがオブジェクト指向プログラミングの本質です。

では、オブジェクトの役割分担とはどういうことでしょうか? 一例をあげてみます。テトリスのようなゲームのオブジェクト構成を考えてみましょう。ざっと Game(ゲーム全体)、Stage(ゲーム画面)、Block(落ちてくるブロック)が思いつきます。底に積み重なったブロックはどう表現しましょうか? Stage オブジェクトに、配列で持ちますか? プレイの制限時間はどうしましょう?  Stage オブジェクトに終了時間を持って監視しますか? どうやらこの調子では、Stage オブジェクトはゲームのほとんどを管理する大きなクラスになってしまいそうです。

そこで、実際のスポーツの試合を考えてみましょう。コートの上にボールは有りますが、「コート」はストップウォッチを持って試合終了の笛を吹いたりはしません。それは審判やタイムキーパーの役目ですね。それと同様に、Stage は「コート」としての役目に徹してもらって、Timekeeper という別のオブジェクトを用意して時間を管理させ、StackedBlocks というまた別のオブジェクトを用意してステージ上に積み重なったブロックを管理させてはどうでしょうか。つまり、役割を分担するわけです。

これで少し役割が分担できました。Timekeeper オブジェクトは時間を管理する役割、StackedBlocksは積み重なったブロックを管理する役割を担うことになります。

また、上のコードで、Stage オブジェクトが Timekeeper オブジェクトと、StackedBlocks オブジェクトを持つことになりますが、これが「包含関係」です。Stage オブジェクトに Timekeeper と StackedBlocks が含まれて(包含されて)いますね。このように、「包含関係」は役割毎に存在する複数のオブジェクトを関連づけるための大切な方法の一つなのです。

オブジェクトを役割分担するメリットは、そのまま「オブジェクト指向プログラミングのメリット」と言えます。オブジェクトが役割毎に分けられると、それぞれのオブジェクトは小さく、そして単純になります。役割の少ない、小さなオブジェクトは、簡潔で見通しが良くなります。シンプルなコードは変更も簡単で保守もしやすいです。また、単純なロジックだけが含まれることで、バグが混入しにくくなります。プログラマは小さくて閉じた世界だけで考えることができるので、自信をもって「論理的に正しい」と言えるコードを書きやすくなり、不安も減るでしょう。また、十分に設計が上手いと、再利用性が高いオブジェクトを作ることもできます。このように、オブジェクトに明確な役割を持たせることで、様々な恩恵を得ることが出来るようになります。これが、オブジェクト指向プログラミングの最も重要な概念です。

4. オブジェクトは役割について責任を持つ

さて、役割が分担された小さなオブジェクトは、もちろん単体では動作しません。アプリケーションの中のオブジェクトは、互いに会話してメッセージをやり取りし、アプリケーションの動作が成り立っていきます。オブジェクト同士の会話は、一般にはメソッドのコールを通じて行われます。

ここで「会話する」という点の理解は重要です。いろんなオブジェクトが存在し、それらが相互に会話してアプリケーションが成り立って行く、という感覚です。そのように組み立てられたプログラムは、一連の処理があちらこちらのオブジェクトに散在することになり、プログラムが上から下に流れて行くようなイメージにはなりません。友人のPHPのプログラマーは、それを「非常に見難い」と評価していましたが、そういうものだと思う方が近道です。実装があちらこちらに散在することに違和感を覚える人は、慣れが必要です。

コツのひとつとして、プログラムの流れを追うのでは無く、オブジェクトがそれぞれの役割を全うすることを意識して見ることがとても大切です。もう少し分かり易く言うと、それぞれのオブジェクトや、オブジェクトのメソッドが正しく動くように小さな単位で考える、ということです。全体を見るのでも、流れを追うのでもありません。そのオブジェクトや、オブジェクトのメソッドが、それぞれ正しく動くようにだけ考えていくことが、役割分担されたオブジェクトと上手く付き合っていく為のコツです。

まとめと発展

以上について、まとめてみました。

  • クラスや継承は、いったん忘れた方が、オブジェクト指向を理解し易い
  • 「包含関係」は大切なので必ず抑える
  • オブジェクトはそれぞれに個別の役割を持つものと意識する
  • オブジェクトが相互に連携してアプリケーションが成り立つものと理解する
  • プログラムは流れでなく、オブジェクトの単位で眺める

ちょっと極端な内容になってしまいましたが、オブジェクト指向がなかなかしっくり来ない方は、今一度リセットしてこの観点で学んでみるのも良いかと思います。学習にあたっては、言語仕様がシンプルでクラス等の雑音の少ない JavaScript が良いように思います。

もちろんクラスや継承も大事だけど…

「クラスや継承は一旦忘れてください」と書きましたが、やっぱり大切ですw。避けて通れない道でもあります。しかし、クラスや継承は、オブジェクト指向プログラミングを扱い易くするための一つの手法に過ぎず、オブジェクト指向の本質では無いことを忘れないでください。例えば「クラス」は、実装の継承手段やオブジェクトの雛形として非常に便利ですが、JavaScript のようにクラスという概念が無い言語でも、別の方法でその目的を実現するものもあります。クラスや継承は、どちらかというと、プログラムの実装の再利用性を高めるための一つのテクニックだと僕は認識しています。

オブジェクトの役割を常に意識する

クドくなりますが、オブジェクト指向で設計やプログラミングをする時は、個々のオブジェクトの役割をしっかりと考えて、それに必要なメソッド(機能)やフィールド(データ)を追加していくことが大切です。便利だからと、安易にオブジェクトに機能を追加するのではなく、「このオブジェクトは本当にこの機能を持つべきなのか?」と疑うぐらいで丁度良いです。場合によっては、新しい種類のオブジェクトが必要になります。慣れないうちは、なるべく擬人化して考えると良いかも知れません。「○○さんは、■■■が役割だから、▲▲▲▲▲は○○さんの仕事だよね」という感じです。

オブジェクトの粒度

オブジェクト指向で設計やプログラムを行っていると、時にオブジェクトが細かくなり過ぎることや、沢山のクラスやファイルが出来てしまうことに戸惑いを感じる事があるかも知れません。少し高度になると、沢山の種類のオブジェクトの存在がメモリや実行速度の問題につながることもあります。あるいは、単に技術的な扱い易さの問題で、1つのオブジェクトに2つ以上の役割を与えたくなることもあります。学習の時点では「役割は細分化する」で良いと思いますが、こと「実践」において、これについて明確に「どうすべき」という指針はありません。それはケースバイケースであり、様々な要素を含めて検討すべき問題です。つまり、実にそれこそが、オブジェクト指向の「設計」の重要なポイントなのです。ですので、個々のプロジェクトの中で、そこは十分に悩んでいただければと思います。

デザインパターン

オブジェクト指向でのプログラムの設計には、幾つかの便利なパターンがあります。最初の頃はお薦めしませんが、オブジェクトを中心に考えることが出来る癖が着いて来た頃に、是非それらを一度勉強してみることをお薦めします。「プログラミング」というものが、優れたアイデアによってより機能的に、よりシンプルに、そしてより美しくなる姿を見る事ができると思います。僕は昔 Java の Collection フレームワークを勉強してとても感動した覚えがあります。またオブジェクト指向による実装の抽象化という概念も、そこから学びました。そんな美しいプログラミングを目にして、感動して、よりプログラミングが好きになれたら僕はとても素敵だなーと思います。

以下に、僕的に「これ知っておいた方がよいなー」と思えるパターンを少しだけ抜き出して紹介してみます。まずは、とりあえず知っておきたい、そして実は良く見掛ける(いつの間にかあなたも使っている筈の)パターンです。説明は何も書きませんので、グーグル先生に教えてもらってください。

  • Factory Method パターン
  • Singleton パターン
  • Observer パターン

また次は、これを知っていると、設計の幅がぐんと広がるゾー的なパターンです。Visitor パターンは僕も最近になって知りましたが、知らなかったのを不幸と思えるほどの強力な武器になりました。オブジェクト指向は奥が深いですね。

  • Strategy パターン
  • Adapter パターン
  • Visitor パターン

 

以上です。ではでは、ハッピーコーディング!

 

 

投稿日:

appfog に PHP + MySQL 環境を作る


appfog」は、とても手軽で簡単な PaaS 環境で、私は最近実験的なプロジェクトや、WordPress の開発環境として利用させて頂いています。今回は、appfog に、プレーンな PHP + MySQL 環境を構築してみましたので、手順を簡単にご紹介いたします。「appfog 簡単そう!」って思ってもらえると幸いです。

セットアップ

アプリケーションの作成(Webサーバー)

まず、ダッシュボードから、Create App に入り、PHP 環境を選択します。

 

次に、インフラを選択します。個人的には AWS US  East か HP がお気に入りです(理由は URL が短いからですw)。サブドメインも入力して、[Create App] します。

これだけ httpd 環境が出来るのですから、素晴らしいですね!
処理完了後、上の図の例では、http://c5.aws.af.cm にアクセスすると、既にHello World が表示されます。

サービスの作成(MySQL)

次に MySQL をセットアップします。

アプリの管理画面の Services のセクションを開きます。
画面下の方、Provision Service のセクションから、MySQL を選び、DB 名を入力してから、[Create] します。

これだけで、アプリケーションから利用できる MySQL のセットアップが完了です。

DBへの接続情報を取得するには

さて、PHP から MySQL へ接続情報はどのように入手できるでしょうか?

appfog の場合、DB 接続の為のホストや、ユーザー名、パスワードといった情報は、VCAP_SERVICES という環境変数より JSON で取得できます。appfog のドキュメントだと、次ページに関連の記述があります。

http://docs.appfog.com/services/overview

この環境変数を取得し、JSON をパースして DB アクセス情報を取得する PHP スクリプトは以下のようになります。

 

以上、ということで、簡単ですねー! DB接続情報の取得は少々面倒に思われるかも知れませんが、全体を通してとてもシンプルで扱い易い PaaS 環境です。無料の基本利用枠があり、トラフィックさえ少ない感じなら5サイトぐらいは運用できそうです。環境を作ったり削除したりも Web の管理画面から簡単に出来たり、これまで使った PaaS の中では一番気に入っています。

ちなみに、好きなものを好きと言ってるだけです。ステマじゃありませんのであしからず♪

 

投稿日:

PHPFog/AppFog と WordPress とファイル管理


以前の記事「PHPFog と WordPress とファイル管理」からのアップデートです。

WordPress は管理画面からサイト自体に様々なカスタマイズが行えることが特徴であり強みです。管理画面からテーマやプラグインをインストールすると、基本的に wp-contents 内に必要なファイルがダウンロードされて追加されます。PHPFog や AppFog などの環境上に WordPress をデプロイしてもこれは同様なのですが、実はちょっと困ったことがあります。

問題

PHPFog では、初期にデプロイされた後、WordPress の管理画面で行った変更については、git clone でも pull でも取得できません。AppFog もツールや方法は異なるものの同様です。つまり、最後に push(update)した変更しか取得することが出来ないわけで、そうなると当然ながら、テーマやプラグイン、また画像などのメディアファイルなど、WordPress の管理画面から追加されたファイルを手元に取得することが困難です。また取得が困難なだけでなく、手元のファイルをアップデートしてサーバーに push (update)しようものなら、それらのサーバーにしか無いデータが消えてしますことがあります。

解決策

プラグイン「BackWPup」を利用します。
http://wordpress.org/extend/plugins/backwpup/

BackWPup は、WordPress のデータベースの中身やファイル等の全てをバックアップできる強力なバックアップツールです。バックアップするファイルは、別の FTP サーバーはもちろん、DropBox、Amazon S3、Google Strage、MS Azure といった様々な媒体に転送できます。バックアップのセットアップもとても簡単です。

このプラグインを用いて、例えば、バックアップ先に DropBoxを指定してバックアップを実行させます。BackWPup の処理が完了し、しばらくしたら DropBox の中の指定したディレクトリにちゃんとバックアップファイルが転送されています。これを解凍して、手元の WordPress の wp-contents を更新し、改めて PHPFog や AppFog に push/update します。

以前の記事「PHPFog と WordPress とファイル管理」では、navphp というファイルエクスプローラ利用しましたが、それよりもずっと簡単に、しかも副次的に(?)サイトのバックアップまで取得できるので大変スマートな方法だと思います。

BackWPup のインストール

管理画面の「プラグイン」>「新規追加」から通常通りインストール、有効化してください。
「BackWPup」で検索できます。

ローカルの WordPress データを最新にするまでの流れ

  1. [BackWPup] > [Add New] から、新規 Job を追加する
    • 設定項目は大変多いですが、とりあえずほとんどデフォルトのままでOK
    • バックアップファイルの転送先のみ注意して入力する
  2. [BackWPup] > [Jobs] で Job 一覧を開いて、作成した Job を [Run Now] で実行する
  3. 指定したファイル転送先にファイルが転送されるので、ファイルを取得する
  4. ローカルの WordPress ファイルをアップデートして、サーバーに push/update する

 

 

以上です。

 

 

投稿日:

第16回 WordBench神戸にて発表させて頂きました。


2012年10月13日(土)の、「第16回 WordBench神戸」にて、『オートページローディングやってみました(WP界のプリンスが挑戦してたので)』という内容のライトニングトークをさせて頂きました。内容は WordPress プラグイン『Infinite Scroll』の紹介です。

以下に、その時のスライド資料を公開いたします(資料公開にあたって、スライドタイトルのみ変更させて頂いています)。

 

次は、今回の発表一覧です。

  1. WordPress のおすすめスライドとか記事とか集めました(上村さん @uemera)
  2. WordPress プラグイン「Infinite Scroll」を試してみた(野島 @yuka2py)
  3. カスタム投稿/フィールド/タクソノミーを自由自在!「Types」をご紹介(細谷さん @tkc49)
  4. WordPress ならではの CSS の書き方を紹介(中本さん @bren_boss)

今回、私の発表は「Infinite Scroll」というプラグインの紹介です。発表にあたって自分のサイトに導入するなどして使ってみました。次ページを Ajax で読み込んで DOM に追加するプラグインで、機能はシンプルながら、WordPress 自体の仕組みを上手く利用するように作られてあるため、大変自由度が高く扱い易いプラグインとなっているように思います。アイデア次第では、色々な用途に利用できそうです。また、Ajax や Javascript まわりを学びたい方は、このプラグインのアイデアを真似て、類似の昨日を実装してみるのも面白いテーマになりそうです。

他の皆さんの発表では、個人的には上村さんの発表がとても参考になりました。ネット上に公開されている WordPress 関連の興味深い資料やWebサイト、Webページなどを一挙にご紹介いただいた内容で、WordPress を学ぶ上で大変参考になる情報だったと思います。既にスライドが公開されているのでURLを掲載させて頂きます。
http://toyao.net/xoops/modules/wordpress/archives/5659

また、細谷さんの「Types」プラグインの紹介も大変参考になりました。WordPress の三種の神器と紹介、「カスタムフィールド」「カスタム投稿タイプ」「カスタムタクソノミー」を一挙に扱うプラグインが「Types」です。このプラグインは使ったことが無かったのですが、非常に豊富な機能があり、驚きました。カスタム投稿タイプに親子関係(リレーション的なもの)を設定できることも特筆すべき点かと思います。近く WordPress のカスタマイズ案件の予定があるので導入して実践してみたいと思いました。

中本さんの発表は、少し時間が押してしまって最後までお話を伺うことが出来なかったのがとても残念でしたが、中本さん流の WordPress での CSS の扱い方が紹介され、これも参考になられた方もあったかと思います!

今回の WordBench 神戸は全体にアットホーム雰囲気でとても良い勉強会でした。また来月も開催されます。すごく美しいデザインをされるあの方の発表が聞けるというような話で楽しみです。…というか、WordCamp の翌週ですが…、僕は行けるのかしら? (; ^ω^)