ノートパソコンを買ったので、ubuntu8.0.4をインストール。
ubuntuのインストール…簡単だなー。
今インストールしてから行なった設定をまとめ中。
忘れてしまうのがいくつかあるから…備忘録って大事だよね。
ubuntuのインストール…簡単だなー。
今インストールしてから行なった設定をまとめ中。
忘れてしまうのがいくつかあるから…備忘録って大事だよね。
買った。BUMP OF CHICKENの最新アルバム。
今まで借りるだけだったんだけど、ブックレットが
素敵だったから思い切って購入。
才悩人応援歌かっこいいよ。
プラネタリウムは懐かしくなった…時間が経ったんだなーって。
さて、もう一回聞こうっと。
今まで借りるだけだったんだけど、ブックレットが
素敵だったから思い切って購入。
才悩人応援歌かっこいいよ。
プラネタリウムは懐かしくなった…時間が経ったんだなーって。
さて、もう一回聞こうっと。
Dockを色々試していたんだけど、どれもしっくりこなかったから使ってなかった。
ところが今日Cairo-Dockというものを見つけて使ってみたら…良い。
これから常用していこうと今設定中。インスト&設定に関する説明は
Cairo-Dock - Community Ubuntu Documentationが詳しいと思う。
Macのテーマを選択すれば、アイコンとかほとんど同じ。知らない人が見ればMacじゃんと言ってしまうかも。
他にも色々テーマがあるけど、結局選択したのはデフォルト。やっぱりデフォルトですよー。
と言いつつ、かなり変更したからデフォルトじゃなくなってる。自分仕様が一番ですな。
ところが今日Cairo-Dockというものを見つけて使ってみたら…良い。
これから常用していこうと今設定中。インスト&設定に関する説明は
Cairo-Dock - Community Ubuntu Documentationが詳しいと思う。
Macのテーマを選択すれば、アイコンとかほとんど同じ。知らない人が見ればMacじゃんと言ってしまうかも。
他にも色々テーマがあるけど、結局選択したのはデフォルト。やっぱりデフォルトですよー。
と言いつつ、かなり変更したからデフォルトじゃなくなってる。自分仕様が一番ですな。
ちょっと間があったけど、次のパターン。
次は decorator パターン。decorator は日本語で装飾者。
言葉通りオブジェクトを装飾していく。どうでもいいけど装飾って
言うよりラップ（包む）するって言った方がイメージしやすい。
オブジェクトをラップしていく。さ、覚えるぞー。
まずは材料を確認。当たり前だけど、
ラップされるオブジェクト(component)とラップするオブジェクト（decorator）。
ところでラップしたとき、ラップされたものとラップしたものはどんな関係？
ラップしたものはラップされたものを持っているね。オブジェクト指向で考えると…そう、Has-a関係。
そこで、ラップするもの(decorator)にはラップされるもの(component)を持たせとく。
これが decorator パターン。継承したものをコンポジション。これ重要。
ラッピングの仕方は至って簡単。ラップされる（したい）オブジェクトを渡してやればいいんだから。
後は好きなように使ってね。このパターンを使えば、プログラムの実行時に機能拡張できることが分かるよね。
継承でも同じ処理を行なう拡張はできるよ。ただ、継承を用いると静的にしか拡張できない。
つまり、コンパイル時に処理内容が決まってしまう。その点、decorator パターンは柔軟だね。
java.ioパッケージは、decoratorパターンを使っている。
だからdecoratorパターンを知れば、I/Oクラスについてより深く理解できるよ。
まとめ。decoratorパターンを覚えるのに重要なのは、
ラップするオブジェクト（decorator）で、継承したものをコンポジション。
使いどころがたくさんありそうなパターンだね。
次は decorator パターン。decorator は日本語で装飾者。
言葉通りオブジェクトを装飾していく。どうでもいいけど装飾って
言うよりラップ（包む）するって言った方がイメージしやすい。
オブジェクトをラップしていく。さ、覚えるぞー。
まずは材料を確認。当たり前だけど、
ラップされるオブジェクト(component)とラップするオブジェクト（decorator）。
ところでラップしたとき、ラップされたものとラップしたものはどんな関係？
ラップしたものはラップされたものを持っているね。オブジェクト指向で考えると…そう、Has-a関係。
そこで、ラップするもの(decorator)にはラップされるもの(component)を持たせとく。
これが decorator パターン。継承したものをコンポジション。これ重要。
ラッピングの仕方は至って簡単。ラップされる（したい）オブジェクトを渡してやればいいんだから。
後は好きなように使ってね。このパターンを使えば、プログラムの実行時に機能拡張できることが分かるよね。
継承でも同じ処理を行なう拡張はできるよ。ただ、継承を用いると静的にしか拡張できない。
つまり、コンパイル時に処理内容が決まってしまう。その点、decorator パターンは柔軟だね。
java.ioパッケージは、decoratorパターンを使っている。
だからdecoratorパターンを知れば、I/Oクラスについてより深く理解できるよ。
まとめ。decoratorパターンを覚えるのに重要なのは、
ラップするオブジェクト（decorator）で、継承したものをコンポジション。
使いどころがたくさんありそうなパターンだね。
今日はビールを購入。迷ったけどキリンの一番絞りを選択。
おつまみには柿の種。
ビールはワイングラスに注ぐ。微妙なこだわり。
バックミュージックはCarpenters。
たまにしかしない。だから良い。
おつまみには柿の種。
ビールはワイングラスに注ぐ。微妙なこだわり。
バックミュージックはCarpenters。
たまにしかしない。だから良い。
java.util パッケージの Observer インターフェースと Observable クラスを使って
Observer パターン。
Observer と Observable についてはそれぞれ参照。リファレンスは使っていかないとね。
Observable クラスに setChanged() というメソッドがある。このメソッドは、
監視している対象が変更されたことをオブジェクトに教える（true をセットする）ためのもの。
notifyObservers（Observer への通知）は true なら通知、
false なら何もしないようになってる。これで変更されるたびに通知なんていう状況はなくなるね。
これらを使えば、一から実装しなくてもいいから便利だね。
…と言いたい所だけど、弊害もないわけじゃない。
1 つ目。protected で保護されたメソッドがいくつかあるよね。
これらを利用するには、サブクラス化しないとどうしようもない。
要は Observable クラスのオブジェクトを作成しても意味ないよってこと。
必ずサブクラス化しなさいってこと。
2 つ目。Observable がクラスだってこと。
java では複数のクラスを継承できない…てことは他のスーパークラスを
継承しているクラスには追加できないってことになる。これじゃ再利用性が下がるね。
でも、こういう問題点を把握しておけばこれらを適切に利用できるようになるよね。
Observer パターンを独自に実装しても良いし、利用可能なら Observable クラスを
使うのも良い。適切な方を選択するべし。
最初に言ったけど Observer パターンは JDK でよく使われてる。
例えば Swing。Swing ではオブザーバのことをリスナって呼ぶ。
リスナの追加・削除、イベントの監視。これは間違いなく Observer パターンだね。
Observer パターン。
Observer と Observable についてはそれぞれ参照。リファレンスは使っていかないとね。
Observable クラスに setChanged() というメソッドがある。このメソッドは、
監視している対象が変更されたことをオブジェクトに教える（true をセットする）ためのもの。
notifyObservers（Observer への通知）は true なら通知、
false なら何もしないようになってる。これで変更されるたびに通知なんていう状況はなくなるね。
これらを使えば、一から実装しなくてもいいから便利だね。
…と言いたい所だけど、弊害もないわけじゃない。
1 つ目。protected で保護されたメソッドがいくつかあるよね。
これらを利用するには、サブクラス化しないとどうしようもない。
要は Observable クラスのオブジェクトを作成しても意味ないよってこと。
必ずサブクラス化しなさいってこと。
2 つ目。Observable がクラスだってこと。
java では複数のクラスを継承できない…てことは他のスーパークラスを
継承しているクラスには追加できないってことになる。これじゃ再利用性が下がるね。
でも、こういう問題点を把握しておけばこれらを適切に利用できるようになるよね。
Observer パターンを独自に実装しても良いし、利用可能なら Observable クラスを
使うのも良い。適切な方を選択するべし。
最初に言ったけど Observer パターンは JDK でよく使われてる。
例えば Swing。Swing ではオブザーバのことをリスナって呼ぶ。
リスナの追加・削除、イベントの監視。これは間違いなく Observer パターンだね。
オブジェクト指向でプログラミングしていく時はこうした方が
良いってことがいくつかある。
1 つは オブジェクト指向 のカプセル化にあるように
変化する部分をカプセル化するってこと。基本中の基本だけど難しい…
同じくらい重要なのが、インターフェース。
インターフェースはポリモーフィズムをうまく使っている方法だね。
さて今まで 2 つのパターンを見てきたけど、具象実装に対してプログラミングしないことになるよね。
必ずインターフェースに対してプログラミングすることになる。
例えば、strategy パターン（observer パターンもそうだけど）では
コンポジション（Has-a 関係）しているよね。そこで戦略を利用する側では何に対して
プログラミングするかっていうと、作成されたインターフェースに対して
プログラミングする。具象実装には一切触らない。
こうすると依存関係が少なくなるから（具象実装に対してプログラミングしたところを想像してみる）、
具象実装の再利用、交換、追加、削除などが簡単になる。
これが実装に対してではなく、インターフェースに対してプログラミングするってこと。
これは覚える。
具象実装に対してプログラミングしたところを想像してみる
例えば、戦略を交換するときどうすればいいだろう。if 文で解決できそうだけど、
それは再利用や交換などを行なうのが容易じゃないのは明らかだし、保守性も悪そう。
具象実装に対してプログラムすると良くないってのが分かる。
良いってことがいくつかある。
1 つは オブジェクト指向 のカプセル化にあるように
変化する部分をカプセル化するってこと。基本中の基本だけど難しい…
同じくらい重要なのが、インターフェース。
インターフェースはポリモーフィズムをうまく使っている方法だね。
さて今まで 2 つのパターンを見てきたけど、具象実装に対してプログラミングしないことになるよね。
必ずインターフェースに対してプログラミングすることになる。
例えば、strategy パターン（observer パターンもそうだけど）では
コンポジション（Has-a 関係）しているよね。そこで戦略を利用する側では何に対して
プログラミングするかっていうと、作成されたインターフェースに対して
プログラミングする。具象実装には一切触らない。
こうすると依存関係が少なくなるから（具象実装に対してプログラミングしたところを想像してみる）、
具象実装の再利用、交換、追加、削除などが簡単になる。
これが実装に対してではなく、インターフェースに対してプログラミングするってこと。
これは覚える。
具象実装に対してプログラミングしたところを想像してみる
例えば、戦略を交換するときどうすればいいだろう。if 文で解決できそうだけど、
それは再利用や交換などを行なうのが容易じゃないのは明らかだし、保守性も悪そう。
具象実装に対してプログラムすると良くないってのが分かる。