参考： http://tomowatanabe.hatenablog.com/entry/2014/04/21/095650

Mosquitto はデフォルトで 1883 ポートを使用するので，必要に応じてポートを開放する．

## on CentOS6

### Mosquitto のインストール

```
cd /etc/yum.repos.d/
sudo wget http://download.opensuse.org/repositories/home:/oojah:/mqtt/CentOS_CentOS-6/home:oojah:mqtt.repo
yum install mosquitto
```

### Mosquitto の起動

```
sudo /etc/rc.d/init.d/mosquitto start
```

### Paho クライアントの導入

```
# python, pipが入ってなければ入れる
sudo yum install python
wget https://raw.githubusercontent.com/pypa/pip/master/contrib/get-pip.py
python get-pip.py
pip install mosquitto

# Pahoクライアントを導入
sudo pip install paho-mqtt
```

### Pub/Sub

```
wget https://gist.githubusercontent.com/tomovwgti/11048251/raw/705036b16326871a58bf01a3fa9b765eea28ac44/pub.py
wget https://gist.githubusercontent.com/tomovwgti/11047563/raw/fd2dd031b7bb3533f1f4626967db9439b315ca2f/sub.py

vim pub.py
# ホスト名を書き換える

vim sub.py
# ホスト名を書き換える

python sub.py
python pub.py  #=> message 0 Hello MQTT!
```


Mosquitto の導入

## 参考リンク

- [GoF の 23 のデザインパターンを，Java で活用するための一覧表　（パターンごとの要約コメント付き）](http://d.hatena.ne.jp/language_and_engineering/20120330/p1)
- [9. Bridge パターン](http://www.techscore.com/tech/DesignPattern/Bridge.html/)
- [Java8 のインタフェース実装から多重継承と Mixin を考える](http://equj65.net/tech/java8mixin/)
- [Java8 で最もインパクトのある構文拡張、デフォルトメソッド](http://d.hatena.ne.jp/nowokay/20130610)

## 機能と実装の違い

ある数列[1,3,2,5,4]をソートしたいとします．このときソートの方法は何通りかあります．このとき「ソートをする」ということが機能にあたります．そして「ソートをする方法」，たとえばクイックソートやマージソートなどが実装にあたります．クラスを拡張しようとするときには，具体的には「機能の拡張」と「実装の拡張」のいずれかであることが多いです．

## Bridge Pattern が必要になる状況例

[TECSCORE](http://www.techscore.com/tech/DesignPattern/Bridge.html/)にわかりやすい例が載っていたので，それに添って Bridge パターンが必要になるシチュエーションを見てみます．ソート機能を持つ抽象クラス`Soter`に対して，実装クラス`QuickSorter`と`BubbleSorter`を以下のように作成したとします．機能は`Soter`，実装は`QuickSorter`, `BubbleSorter`に分離されていることに注意します．

```java
public abstract class Sorter {
    public abstract void sort(Object obj[]);
}

public class QuickSorter extends Sorter {
    public void sort(Object obj[]){
        // クイックソートで obj[] をソートする
    }
}

public class BubbleSorter extends Sorter {
    public void sort(Object obj[]){
        // バブルソートで obj[] をソートする
    }
}
```

現状のコードに新しい「実装」を増やすことは容易いです．単に`Soter`を extends した実装クラスを書けば良いだけだからです．しかしながら新しい「機能」を増やすためにはどうしたら良いでしょうか．ためしにソートに加え，それにかかった時間を表示する機能を追加したい場合を考えてみます．するとコードは以下のようになります．

```java
public abstract class TimerSorter extends Sorter {
    public void timerSorter(Object obj[]){
        long start = System.currentTimeMillis();
        sort(obj);
        long end = System.currentTimeMillis();
        System.out.println("time:"+(end - start));
    }
}
```

ソートの実装自体は先ほど実装してある`QucickSort`, `BubbleSort`クラスを使いたいとします．しかしながらよくよく考えてみると`TimeSorter`にそれらの実装を与えることができません(Java1.7 以下での話？)．そこで残念ながらそれらの`TimeSorter`に対応した実装クラス`QuickTimeSorter`と`BubbleTimeSorter`を書かなければなりません．図で表すと以下のような具合になります．

<img src="http://53ningen.com/wp-content/uploads/2014/07/L-1.png" alt="l-1" width="538" height="560" class="aligncenter size-full wp-image-686" />

このような状況に上手く対処するために Bridge Pattern が用いられます．

## Bridge Pattern

Bridge Pattern では実装の部分を別の階層に切り離すことによって，これまでに見てきた例のような問題を解決します．まずはコード例を見てみます．

```java
public class Sorter {
    private SortImpl sortImpl;
    public Sorter(SortImpl sortImpl) {
        this.sortImpl = sortImpl;
    }
    public void sort(Object obj[]) {
        sortImpl.sort(obj);
    }
}

public abstract class SortImpl {
    public abstract void sort(Object obj[]);
}

public class QuickSortImpl extends SortImpl {
    public void sort(Object obj[]) {
        // クイックソートで obj[] をソートする
    }
}

public class BubbleSortImpl extends SortImpl {
    public void sort(Object obj[]) {
        // バブルソートで obj[] をソートする
    }
}
```

このように機能を実現するための方法が`SortImpl`に`委譲`されているため，実装の追加はもちろん，機能の追加は容易になります．まとめとして Bridge Pattern のクラス図を示しておきます．

<img src="http://53ningen.com/wp-content/uploads/2014/07/L-2.png" alt="l-2" width="428" height="304" class="aligncenter size-full wp-image-687" />

> 時間経過に伴って機能が拡張されていくバージョンアップの過程と，実装タイプのバリエーションを豊富に広げる品揃えの充実具合を，別個に分けて，整理して管理できる([GoF の 23 のデザインパターンを，Java で活用するための一覧表より](http://d.hatena.ne.jp/language_and_engineering/20120330/p1))

## Java8 での機能と実装の追加について考えてみた．

この部分については個人的に思いついた内容なので，実際に良い方法なのか微妙なところですが，とりあえず書いておきます．Java8 ではインターフェースがデフォルト実装を持てるようになったため，先の例ででてきた`Sorter`を抽象クラスではなくインターフェースとして定義しておけば，「実装の拡張」はもちろん，「機能の拡張」もすっきりおこなえるかなと思いました．ソートにかかる時間を表示する timeSort 機能を追加したあとのクラス的にはこんな具合になると思います．

<img src="http://53ningen.com/wp-content/uploads/2014/07/L-3.png" alt="l-3" width="538" height="290" class="aligncenter size-full wp-image-688" />

現時点でこの方法が抱えている問題は，`Sorter`が抽象クラスではなくインターフェースになったので状態（プロパティ）を持てなくなってしまったという点だと考えていますが，どうでしょうか．


Bridge Pattern

状況・文脈（context）によって動的に振る舞いを変えたいときの定石が Strategy Pattern です．
たとえば各 OS 向けに文字列を出力する`TextPrinter`クラスがあるとします．
ところが各 OS 標準で用いられる改行コードはことなるのでその部分についての振る舞いを OS によって変えなければなりません．
以下はこういう状況のときにありがちなコード例です．

```java
public class TextPrinter {
    private OSType os;
    private String printNewLineChar() {
        if(os == OSType.WINDOWS)
            return //CR+LF
        if(os == OSType.MAC)
            return //CR
        if(os == OSType.UNIX)
            return //LF
        return null;
    }
}
```

往々にして if 文の嵐になります．そこで改行コード出力のふるまいだけを抜き出して，オブジェクトとして扱ってしまおうというのが Strategy Pattern になります（言い過ぎ？）．どの環境下でのふるまいも共通して「改行コードを出力する」という責務を持っているのでインターフェースを決めておくと便利です．今インターフェース Compositor を定義し，その後に各々の環境に応じた実装をしていくと良いです．

```java
interface Compositor {
    pubic String printNewLineChar();
}

public class WindowsCompositor {
    @Override
    public String printNewLineChar() {...};
}

public class MacCompositor {
    @Override
    public String printNewLineChar(){...};
}

public class UnixCompositor {
    @Override
    public String printNewLineChar(){...};
}

public class TextPrinter {
    privte Compositor compositor;
    pubic TextPrinter(Compositor compositor) {
        this.compositor = compositor
    }
    public String printNewLineChar() {
        return compositor.printNewLineChar();
    }
}
```

このようにスッキリしました．今やったことを抽象化した Strategy Pattern のクラス図は以下のようになります．

<img src="http://53ningen.com/wp-content/uploads/2014/07/L-4.png" alt="l-4" width="538" height="280" class="aligncenter size-full wp-image-694" />

> 【参考：GoF 本での定義】アルゴリズムの集合を定義し、各アルゴリズムをカプセル化して、それらを交換可能にする。
> Strategy パターンを利用することで、アルゴリズムを、それを利用するクライアントからは
> 独立に変更することができるようになる。

> アルゴリズム実装のための専用オブジェクトを複数作っておき，その中から使うものだけを動的に選んで実行する。
> ある程度複雑なアルゴリズムになると，ふつうのプログラマであれば，その部分を切り出して集約するだろう。また，他のアルゴリズムに置き変わった時に備えて，互換性も持たせておくだろう。なので，あまり新規性を感じないパターンに思えるかもしれない。とはいえ，アルゴリズムの交換可能性を増すために，共通の基底（または共通のインタフェース）を持たせているという点は注目。（[GoF の 23 のデザインパターンを，Java で活用するための一覧表より](http://d.hatena.ne.jp/language_and_engineering/20120330/p1)）

## Bridge Pattern と Strategy Pattern の違い

よくわからなかったので，GoF 本の適用可能性の欄を参照しました．

> - Bridge Pattern（構造に関するパターン）

    - 抽出されたクラスとその実装を永続的に結合することを避けたい場合．
    - 抽出されたクラスとその実装の両方を，サブクラスの追加により拡張可能にすべき場合
    - 抽出されたクラスの実装における変更が，クライアントに影響を与えるべきではない場合
    - 複数オブジェクトの間で実装を共有したい場合

> - Strategy Pattern（振る舞いに関するパターン）

    - 関連する多くのクラスが振る舞いのみ異なっている場合
    - 複数の異なるアルゴリズムを必要とする場合．
    - アルゴリズムが，クライアントが知るべきではないデータを利用している場合．
    - クラスが多くの振る舞いを定義しており，これらがオペレーション内で複数の条件文として現れている場合．

ここから察するに，Bridge Pattern は継承より委譲を使うことにより，インターフェースとその実装の結合を弱め，「機能」と「実装」を柔軟に拡張できる構造を作りたいときに使うパターン．そして Strategy Pattern は状況に応じ振る舞いが変わるような状況下でその振る舞いの部分を切り出し，クラスの肥大化・複雑化を避けたり，あるいはクラスと振る舞いの結合を弱めるために使われるのではないかと思いました．間違いがあったらご指摘いただけるとありがたいです．

### 参考リンク

- [State パターンと Strategy パターンは何が違うのか考える ](http://lab.tricorn.co.jp/toda/1088)
- [stackoverflow: Strategy vs. Bridge Patterns](http://stackoverflow.com/questions/5863530/strategy-vs-bridge-patterns)
- [【デザインパターン】【GoF】【C#】ストラテージ（Strategy）パターン](http://blogs.yahoo.co.jp/dk521123/24787700.html)


53ningen.com

@gomi_ningen's Website

Mosquitto の導入

on CentOS6

Mosquitto のインストール

Mosquitto の起動

Paho クライアントの導入

Bridge Pattern

参考リンク

機能と実装の違い

Strategy Pattern

About

Pinned Articles

Lab

Categories

Tags

Archives