目次

1. クラス（クラスメソッドとクラス変数）
2. 継承
3. モジュール
4. 例外処理

前回はクラスを作り、インスタンスメソッドを使うところまでを記載しました。今回はクラスメソッドの書き方から始めたいと思います。

1. クラスメソッドとクラス変数

class EnglishTest
#クラスメソッド
=begin
def クラス名(もしくはself).メソッド名
  実行したい処理
end
=end
  def EnglishTest.title(title)
    print title,"テストの点数を発表します。\n"
  end
end
#クラスメソッドの呼び出し
EnglishTest.title("英語")

クラスメソッドは、def クラス名(もしくはself).メソッド ~ endで表します。クラスメソッドを呼び出すには「クラス名.メソッド名」と書きます。

複数のクラスメソッドを纏める書き方もあります。

class EnglishTest
#発表した人数をカウント
  @@count=0

#初期化メソッド
  def initialize(name="Ruby",point=0)
    @name=name  
    @point=point
  end
#アクセスメソッド
  attr_reader :name,:point
  
#インスタンスメソッド
  def test
   @@count+=1
   print(@name,"さんの点数は",@point,"点\n") #()省略可
  end
 
#クラスメソッド
  class << EnglishTest
    def title(title)
      print title,"テストの点数を発表します。\n"
    end

    def count
      @@count
    end
  end
end

#クラスメソッドの呼び出し
EnglishTest.title("英語")

#オブジェクトの生成
ruby=EnglishTest.new
tanaka=EnglishTest.new("田中",60)
takahashi=EnglishTest.new("高橋",80)
#メソッド呼び出し
ruby.test
tanaka.test
takahashi.test
#クラス変数の呼び出し
puts EnglishTest.count,"人の点数を発表しました。\n"

クラスメソッドを複数書く場合はclass << EnglishTest ~ endの中に書きます。インスタンスメソッドと同じような書き方ができ、わかりやすくなります。

@@で始まる変数はクラス変数と呼ばれるものです。このクラスのすべてのインスタンスで共有できる変数です。クラス変数を参照するには自分でアクセスメソッドを用意しなければいけません。上記ではtestメソッドが呼び出される回数を記録しています。

以下は実行結果です。

英語テストの点数を発表します。
Rubyさんの点数は0点
田中さんの点数は60点
高橋さんの点数は80点
3
人の点数を発表しました。

２. 継承

class Human
  def initialize(name="you")
    @name=name
  end

  def morning
    print "おはよう\n"
  end

  def hello
    print "こんにちは, ", @name,"さん\n"
  end 
end

#継承の構文
#class クラス名 < スーパークラス ~ end
class John < Human
  def morning
    print "Goodmorning\n"
  end
  
　　def bye
　　　　　print "Goodbye\n"
 end
end

john=John.new("John")
john.morning
john.hello
john.bye

スーパクラスがHuman,サブクラスがJohnになります。スーパークラスのmorningメソッドをサブクラスのmorningメソッドでオーバーライド（上書き）し、サブクラスで新しいbyeメソッドを追加しています。スーパークラスのinitializeとhelloメソッドはサブクラスには記載されていませんが、継承されているので、呼び出すことができます。

Goodmorning
こんにちは, Johnさん
Goodbye

３. モジュール

モジュールはクラスと書き方が似ていますが、クラスと違いインスタンスを持つことができません。また継承もできません。処理だけを纏める機能を持ちます。以下のように記載します。

#モジュール作成
=begin
構文
module モジュール名
  モジュールの定義
end
=end

module AbcModule
 Number="1.0"  #定数

 def hello(name)
 print name,"さん、こんにちは\n"
 end 
#モジュール関数として登録
 module_function :hello
end

p AbcModule::Number
AbcModule.hello("John")

include AbcModule
p Number
hello("Sara")

モジュールは「モジュール名.メソッド名」という形で参照できます。これをモジュール関数といいます。注意しなければいけないのは、モジュール関数を定義しただけでは、モジュール名.メソッド名で呼び出せません。module_functionでモジュール関数を外部に公開して呼び出せるようになります。

モジュールをincludeすることによって、モジュール名を省略することができます。

"1.0"
Jognさん、こんにちは
"1.0"
Saraさん、こんにちは

モジュールをクラスにインクルードすることを「Mix-in」とよびます。モジュール内のメソッドなどをクラスに取り込むことができます。

module AbcModule
  #Class1とClass２で共通のメソッドをまとめる
end

class Class1
  include AbcModule
  #固有のメソッドを記載
end

class Class2
  include AbcModule
  #固有のメソッドを記載
end

４. 例外処理

プログラム実行で起きるエラーは以下のものがあります。

• データのエラー
• システムのエラー
• プログラムのエラー

例外処理はこのようなエラーが発生した際に、実行されます。今回はraiseメソッドを使って、自分で例外を発生させます。

class ErrorTest
=begin
  begin
    例外が発生するかもしれない処理
  rescue
    例外が発生した際の処理
  end
=end  
  def initialize(name)
    @name=name
  end
 
  def hello
    begin
      raise
      print @name,"\n"
    rescue
      print "エラーが発生しました。\n"
    end
  end  
end

john=ErrorTest.new("John")
john.hello

例外処理は、begin~rescue~endを使います。beginに例外が発生するかもしれない処理を書き、rescueに例外が発生した際の処理を書きます。

上記では例外が発生するかもしれない処理の中でまずraiseメソッドが呼ばれ、その後printメソッドが呼ばれています。しかしraiseメソッドは例外を起こすメソッドなので、このメソッドが呼ばれた時点でrescueに処理が移ります。処理が移ったので、rescue側のprintメソッドが呼ばれ、以下が実行結果として出力されます。

エラーが発生しました。

早足でRubyを紹介してきましたが、いかがでしたでしょうか？
Rubyが気になった方は是非、開発環境を整えて、コードを書いてみてください。
次回はRubyのフレームワークであるRailsの紹介をしたいと思います。

依存性注入 = Dependency Injection とはなんぞや？という方のためになるべく簡単にその解説を書いてみたいと思います。

依存性注入（DI）ってむずかしい言葉いったいなんですか？

継続的インテグレーション（CI）もそうですが、日本語に直訳してしまうと、とてつもなくわかりづらいワードになってしまうものがあります。この DI もそうです。

私も初めて Spring を触ったときはこのワードに惑わされた感がありました。だからブログにネタを書くときは絶対に人にわかりやすいように書きたいと思ったものです。依存性注入というのをわかりやすくいうと

クラス同士を疎結合にして、実データは外部へ出しちゃいましょう

ということです。いったいなんのために？

クラスの単体テストをしやすくするためです

下の図のようにクラスAの中でクラスBを呼び出している場合、クラスAがクラスBに依存しているといいます。この場合、クラスAができあがって単体テストを行いたくても、クラスBが出来ていないとそれができません。

では DIコンテナを使った場合はどうなるのでしょうか。下の図を見てみてください。

クラスAはインターフェースXを呼び出しているだけなので、クラスBが出来ていなくても単体テストができます。そう、インターフェースXがモックの代わりになり、実データ（＝リテラル）をクラスBに外出ししているのです。

昔の Spring では実データを XML ファイルに書いていましたが、”脱XML”のトレンドからすれば今は上記のようにインターフェースをかませる方法がスマートと言えるでしょう。もちろん現行の Spring でも XML で設定することは可能です。

単体テストがかんたんにできる以外にもメリットはあります。上図の中で、インターフェースXが検索するパッケージ場所を設定ファイル（これはXML）で管理するのですが、その検索するパッケージを書き換えれば、インターフェースXのデータを本番用の”クラスC”に一瞬で切り替えることが可能です。

ちなみにこの DI機能は、JUnit でも使えるので、テスト駆動開発の場合でも導入できると思います。

いかがでしたか？今日は理解の難しい DI コンテナについて取り上げてみました。DI のデメリットとしてインターフェース数が増えることや、そもそも現場の学習コストの問題もあります。使えば必ずしも品質や納期が改善されるわけではないのでメリット・デメリットを天秤にかけて導入を検討してみてください。

いまや星の数ほどあるオープンソースソフトウェア（以下 OSS）ですが、私たちの仕事にあまりに無意識に入り込んでいるため、ライセンスについてはあまり考えずに使ってしまうこともしばしば。OSS のライセンスが複雑化していることも原因と考えられます。今日はそんな OSS のライセンスについて商用利用という観点から再考するために改めて書きとめておきたいと思います。

　そもそもオープンソースって無料でしょ？

OSS は無料で使えるのは確かです。しかし 負う義務はライセンスにより様々なのです。

無料だからといって何してもOKというわけではありません。

数あるライセンスの中で一番神経を使うのが GPL のようにコピーレフト（後述）であるライセンスです。GPL は商用利用において企業が神経をとがらせ、また敬遠するものであったりもします。

非コピーレフト
MITライセンス, Apacheライセンス, BSDライセンスなど

コピーレフト
GPL, LGPL , AGPL, CPL など

　コピーレフトかどうかが運命の分かれ道

コピーレフトというのは簡単に言えば

「あんた、コピーレフトの OSS を使ってソフトウェア作ったんやな？なら、あんたのソフトウェアも配布した人にソースコード公開せなアカンよ？」

というものです。

例えば、GPL ライセンスのライブラリを使って業務アプリケーションを完成させたとします。するとその業務アプリケーションは GPL ライセンスとなりますので、配布先であるクライアントに業務アプリケーションのソースコードを公開する義務を負います。

これが GPL ウイルスとも言われる理由ですね。

なんだその暴挙は！と思われるかもしれませんが、これにはちゃんと理由があります。GPL の哲学として「オープンソースソフトウェアを独占させず、より広くオープンソースソフトウェアを発展させたい」というものがあります。その想い通り、GPL ライセンスのソフトウェアというのは爆発的に広まっていきました。

しかし、最近はこの扱いにくい性質から非コピーレフトの MITライセンスや Apacheライセンスなどが好まれる傾向が強くなってきたのも事実です。非コピーレフトライセンスの場合、成果物のソースコードを公開する義務はありません。

少し前、PHP フレームワーク CodeIgniter がコピーレフトライセンスを採用すると発表。多くのユーザーが不満を抱き、 FuelPHP へ流れるといったことがありました。その後いざこざがありつつも結局、CodeIgniter3.0 は非コピーレフトである MITライセンスを採用することとなったのです。

　コピーレフトは商用利用には使えない？よくある勘違い

答えはノーです。

具体例を挙げると、コミュニティバージョンの MySQL は GPL ライセンスなので無料ですが、MySQL を使うソフトウェアを作れば GPL を継承することになります。依頼元のクライアントにソースコードを求められたらクライアントにさえソースコードを渡せばいいので、きちんと説明すれば GPL ソフトウェアを使うことも許されるでしょう。

Webサービスだったらユーザー全員にソースコード公開しなくちゃいけないのでは？

答えはノーです。

ソースコードを公開する義務があるのはソフトウェア自体の配布先に対してのみです。WebサービスのユーザーはたしかにWebサービスを利用していますが、ソフトウェアはサーバーにしかなく、ユーザーにソフトウェアを配布しているわけではないからです。

　もしライセンス違反したらどうなっちゃうの？

アメリカでは GPL ライセンス違反を犯した会社が訴訟を受ける事例がありました。日本ではまだ訴訟の事例はないようですが、国内大手の会社が Linux の GPL 違反を犯して、ユーザーから非難を浴び、修正したという事例があります。日本ではまだ訴訟のケースがないからいいや、ということにはなりません。事前に OSS の採用を綿密に考え、万が一、意図せずに違反してしまった場合は速やかに企業として対応する体制が必要です。企業の信頼は失ってからではもう遅いとすら言えます。

　おまけ：　私の周りのライセンスを調べてみた

最後に、私がよく使うソフトウェアやライブラリをざっくりまとめてみました。

・AngularJS （MIT License）

・Spring Framework （Apache License 2.0）

・MyBatis (Apache License 2.0)

・Tomcat (Apache License 2.0)

・Jenkins (MIT License)

・FuelPHP (MIT License)

・jQuery (MIT License)

・MySQL (GPL)

・Redis (BSD License )

・Apache HTTP SERVER (Apache License 2.0)

・NGINX (BSD like)

・Varnish Cache (BSD licence)

いかがでしたか？今日は私たちが普段から使っている OSS についてもう一度その足元を確認するために、ライセンスについて確認してみました。
オープンソースの力は偉大で私たちも多くの恩恵を受けてきたのは事実です。その反面、なかなかそのコミュニティの想いや哲学を知る機会はありません。今回は私自身にとって大変良い学びになりました。

突然ですが、私は今後すべての Web はシングルページ化していくと予想しており、またそうなるべきだと思っています。

今さらですが、従来の Web アプリケーションというと、サーバーサイドで生成したページをクライアント（ブラウザ）に投げつけ、あとはブラウザがそれを表示するだけでした。データに更新があればサーバー側でページを更新してブラウザはそのデータをもう一度読み込み直す。これがサーバー同期通信です。

これには一つ、画面のユーザビリティに大きな欠点がありました。何か操作するためにページ更新が起きるため画面がチラついて「待ち」が発生する。これではユーザーに強いストレスを与え、インストール型アプリより確実に”劣った”コンテンツとなってしまう。

ＢｔｏＣ の Web サービスでは ＳＰＡ が増えてきていますが、私がメインとする業務系も ＳＰＡ 化していくことが目標の一つであったりします。

　フロントエンドを”厚く”するメリット・デメリットとは？

メリット
サーバーサイドとフロントエンド双方のやることが住み分けできて処理がスッキリします。サーバーサイドはデータベース処理とコンテンツの置き場に徹して、コンテンツの組み立てをフロントエンドに寄せます。サーバーサイドで”がんばる”ことを絞り込むことでインフラ設計も立てやすくなります。データ処理とコンテンツの分離ですね。

もうひとつ、同じような html ファイルを量産しなくて済みます。がんばってヘッダやフッタを部品化しても、結局 html ファイル数は増えてしまいますよね。一般的な ＳＰＡ ならヘッダ、サイドバー、フッターが固定で、メインコンテンツだけ Ajax で書き換えていけばいいので html コーディング量がグッと減ります。

双方のインターフェースについても心配はいりません。今時のサーバーサイドフレームワークには REST コントローラーが実装されていますので、簡単に JSON などの APIインターフェースが作れます。そしてフロントエンドの JavaScript と JSON等 でデータのやりとりを行うわけです。

デメリット
クライアント側の処理が重くなります。サーバーから JSON でデータをクライアントに投げた後は、コンテンツ処理はすべてクライアントがやります。ＳＰＡ の場合は常に処理が走りますのでその点をケアする必要があります。もうひとつ、ブラウザが古いとせっかく作ったクールな ＳＰＡ も正常に動かない可能性があります。私が「業務系も ＳＰＡ 化していくことが目標」と書いたのはこれが理由です。どんなに優れた UI/UX を作りたくても

「あーうちの会社、 PC 古いんで昔の IE でも動くようなやつお願いしますね」

Web系の人なら一度は食らうであろう「古いIE砲」には敵わないのである (;ﾟдﾟ)

　最近気になるフロントエンド技術について

最近 AngularJS を使い始めました。Google のアレです。これをつかって Ajax すれば大抵の ＳＰＡ は作れると思います(｀･д･´)
特にフォームからユーザー入力を input で受け取ってリアルタイム表示するモデル機能、js 内にデータを入れて、リアルタイムに絞りこみ検索できるコントローラー機能は強力です。データを表示する際のフィルター機能も充実していてコンテンツ作りが楽しい。フレームワーク依存症になりそうで怖いですｗ

その他気になるもの
・データをグラフィカルに見える化する D3.js
・Ajax と違いサーバープッシュできる WebSocket

いかがでしたか？今日は雑多な考察ブログでした。
次回は最近よく聞く CSS の開発手法について書いてみたいと思います。