著作一覧
著作一覧 |
・雷が鳴ると気が削がれる（らしい）
・キューはCommand（これは僕の純然たる興味。StateとStrategyは明白に相違がわかるんだけど、Commandってどうもわからないんで。実行するやつが選択するのがStrategyで実行するやつが選択しないのがCommandということらしい）
・DxOというのは、どうやら絵に（記号として）描いたときにeXcahngeのXを挟んでDataとObject（どっちでも構わないけど、中が白抜きになった箱）が両脇にあるのがミソではないかと思った
・層ってのは時間とは関係ないんじゃないか？（ここからは直接は関係ない）もちろん関係ない。
・もしレイジーロードとかしている最中のエラーが問題となるのであれば、それはViewの位置が悪いと思う
・POJOはMbVが可能なのがミソだと思うのだが
・アプリケーションロジックという言い方。Smalltalk由来らしい。
・意外なほどIDEデモに感心する（ふりかも）人数がいるのにちょっと驚く。へー
・サービスレイヤーは当たり前
・僕の夏休みはどこへ行ってしまったのでしょうか？（でもリンクはしなかったり）
・3次元フローチャート（というのを思いついた）
・ひがさんと高橋さんは�遒離織鵐�トップ。しかし微妙に色が違う。
・羽生善治。ルールを変えた伝道師（兼勝負師）。なるほどね。
・ジェネリクスは、関数のパラメータが型制約されるのが当然だったのに対して、それ自体をパラメータ化できることを示した（ということかな？）。自然数の世界に対してゼロと負を導入したようなもので、それまでの前提＝世界が、実は単なるサブセットであることを示した、ということなのかなとぼんやりと考える。
・図の→が間違えてるんじゃないかという指摘。RecognitionはProductに対して与えるようにするのが本当。でもまあ例だから。つまりダブルディスパッチすべきとkoichikさんから。
・iBook 12" ほすい……（でもそれどうすんだというのはあるけど）
・ケントベックがデマルコった。でもそれってどんなこった、てらこった。
全然別の話。abortを_NTだったらtlhelp32のAPIに置き換えるで良さそうな気がする。
これ、いい。コンパクトにまとまっているし、用語の用例の宝庫でもある。そう言えば、GUIのViewはModelのことを知り抜いていたな（だから更新通知にはパフォーマンスオプション用のヒントしかなかったりする）。Viewはモデルに対して特化するからだ。
r-matudaさんなのか。
役に立たないよな、と思っていたのだった。
EoDというお題目からいけばIDE重要だから1.は十分にありそうだ。でもどうってことは無い話でもある。2番目は悪質で、そのうちベストプラクティスとして
public class Color {
static final int COLOR_RED = 9;
static final int COLOR_BLUE = 10;
...
}
みたく、COLOR_というようなインポート元を示すプレフィクスを付けましょうとか言い出すようになったりして。それを人は本末転倒と呼ぶ。
でも考えてみたら、thisについては置いておくとして、mix-inなのかも。なら利用価値が見える。
すべてのメソッドは必ずしもインスタンスを触る必要はなくて、それがstaticかそうでないかはデザインによって決定される。別にthisを参照しないからstaticというように機械的に決定できるわけではない。（いや、とんでもない規約でthisを参照していないとstaticにしろ、と文句を垂れるとかしていることもありそうだが、デザインを考えないのならそれはそういうメタデザインなのだから知ったことではない）。
たとえば、文字列操作用の便利メソッドユーティリティがあるとする。それはたとえばStringUtilクラスというような名前がついていて
String after = StringUtil.filterFoo(before);みたく使う。でも、文字列のフィルタをしまくるプログラム（たとえばDisplayableStringBuilderとかしておく）であれば、呼び出し先が外部のユーティリティクラス（StringUtil）のメソッドである必要はない。
public class DisplayableStringBuilder {
StringBuilder buffer;
public DisplayableStringBuilder(String original) { ... }
public String buffer() { return buffer.toString(); }
public String addDecoration(Decoration decoror) { ... }
String filterFoo(String part) { ... } // フィルタメソッド(自前) thisは参照しない
String filterBar(String part) { ... } // 同上
}
しかし、このfilterFooは既にStringUtilに実装されている（というよりも、DisplayableStringBuilder以外のクラスからもガンガン利用可能）。
というような場合に、StringUtilという外部のクラスは無視して、あくまでもDisplayableStringBuilderの自前の延長線上のメソッドとしてStringUtilのメソッドを取り込みたい。
というような場合が、使い道なんだろうな、と『地味だけど便利! - Static Import』を読みながら思った。mixinとは書いていないけどそういうことを言っているのだろう。
| ジェズイットを見習え |
TestCaseでの俺アサーションメソッドとか。と、いうかJUnit4のアサーションはstatic importになる模様。
インスタンスに作用するわけじゃないんですよね？しんたくすしゅが？
>しんたくすしゅが
ですね。でも、thisを混ぜ込むのは可能（と思ったけど、元のメソッドでは参照が浮いてしまうからだめか、と思ったけどコンパイル時解釈ならやっぱり可能。クラスはimportされた数だけ作られることになるけど。今は別に欲しくないけど、プリプロセッサとしてなら簡単に書けるよね）
>Unit4のアサーションはstatic importになる模様
なるほど。それはmixinそのもののような。