Implementation Patterns 第三回勉強会

今回は、5章Implementerから。

インナークラスはうまい使い方がそんなにない。
なんか作ってくうちに、あれ?これインナーじゃなくてもよくね?
と思ったりする。
あとは、まぁ当然のことを理路整然と説明しているなと。
なんか、これすごく分かりやすく翻訳したら新人向けにもいいのかも。

6章は、State。
最初にオブジェクト指向についてのイメージ?が紹介されてた。
Kent Beck氏曰く、クラス=PCらしい。それらがネットワークを組んで分散処理ってイメージ。
私は、もうちょっと人間に近いイメージがある。
(良く伝わるかは別にして)小劇団の喜劇をイメージして欲しい。
登場人物一人一人がクラス(オブジェクト)だ。
それらは、個々に考えを持ちながらも、セリフと動きを元に
1つの世界を演じている。　その世界が私たちプログラマの成果である。

IndirectAccessは、C++(ゲーム作成)時代に良く使っていた。
ゲームは基本的に例外的な操作というのは限られている(想定できる)*1ので、
setter等には、例外値を検出するコードを埋め込むということをよくする。
setterに限らず、ほとんどのメソッドには、事前チェックを入れておく。(当然ながら#IF _DEBUG 〜 #ENDIFで囲む)
こうすることで、ゲームの精度が飛躍的に上昇するってわけ。
ここで紹介されているIndirectAccessの例は、主に数学的事象や図形描画では重宝するが、
業務ロジックでは、これを適用出来る箇所というのは少ないのでは?というのが感想。

Variable Stateはやってはいけない。
Common Stateを用いるか、CommonStateを用意するまでもない場合でも、
Common StateをInnerクラスとして用意するべきだ。

ということで、第三回終了。

私の翻訳担当はAppendixなのだが、
超スローペースにしか翻訳が進まない。
もう完全に意訳しているので、原文そっちのけになってきていなくもないw
とりあえず、早めに完成させて、楽になりたい。

*1:入力がコントローラのみ、環境が限られるため