WEB+DB PRESS Vol.30

WEB+DB PRESS Vol.30

DI時代の Java EE (J2EE) アーキテクチャ

わかりやすくて良い記事だなと思ったけど、ちょっとだけ気になる点があったのでコメント。

P.23
クラス FileAccessorImpl をインジェクトしてもよいのですが、この際なので、もっと楽にテストする方法はないでしょうか。...

FileAccessorImpl を使う場合と、FileAccessorMock を使う場合ではテストの内容が変わると思うんだけど、この書き方だとテストの内容は同じままで、楽になったように読めてしまわないかな?

P.24
サービスロケータパターンにおいても実装をモックに変更することは可能です。前述したように、サービスロケータの処理を変更すれば実装を変更することができるためです。...

サービスロケータでモックを使う場合、僕ならこうすると思います。

// FileScannerImpSl.java (抜粋)
public class FileScannerImpSl implements FileScanner {
  public String scan(String filename) throws Exception {
    FileAccessor accessor = getFileAccessor();
    // 以下、リスト4: FileScannerImp と同じ。
  }
  protected FileAccessor getFileAccessor() {
    return FileAccessorLocator.getInstance().lookup();
  }
}

// FileScannerImpSlTest.java (抜粋)
public class FileScannerImpSlTest extends TestCase {
  public void testScan() throws Exception {
    FileScannerImpSl scanner = new FileScannerImpSl() {
      protected FileAccessor getFileAccessor() {
        String[] s = {"a1", "b2", "c3", "a4", "d5"};
        return new FileAccessorMock(s);
      }
    };
    assertEquals("a1\na4\n", scanner.scan(""));
  }
}

サービスロケータだからといって、それほど難しいことではないと思います。

じゃあ、なぜDIなのかというと、やっぱりコンポーネントからフレームワークへの依存がなくなって、コンポーネントの再利用性が高まるのと、あとはDI使ったほうがエレガントだ(と思う)からかなぁ。

「世界征服」のための問題解決アプローチ

しばらく前だとこういう記事って嫌いだったんだけど、いま読むと「世界征服」というふざけた題材を使いながら、とても問題を的確にとらえていると思った。擦れたのか成長したのか...
ある意味「世界征服」を志すぐらいじゃないと、どんな目的も達成できないのかもしれない。世界から貧困をなくすぞーっていうのも一種の世界征服だし。