プログラムがまだ不慣れな人が「プログラムちょっとわかるようになったけど、まだぜんぜんオブジェクト指向とかできてません」のように言ったり、ちょっと慣れた人が「このソース、ぜんぜんだめ。オブジェクト指向ができてない」にようなことを言ったり、まるで、オブジェクト指向ができてるかどうかがよいプログラムかどうかを表すことになってるようだ。 Javaのアルゴリズムの本に、「Javaなのにオブジェクト指向ができていない」のような書評がついているのを見たときには、お前は何を求めてるんだと思ったりもした。 そのようなオブジェクト指向は、窓から投げ捨てるべきだ。オブジェクト指向はプログラムのよしあしの基準にならない。 むだにHogeインタフェースとHogeImplクラスがあったり、むだにnewするだけのcreateメソッドがあったり、どこで値が設定されてるかわからないオブジェクトがひきまわされてたり、ソースコ

いままでのJavaでは、日付時刻を扱おうとするとめんどくさい割に非常に低機能でした。 Java8では、新たに日付時刻APIが導入され、めんどくささが増しつつ非常に高機能になりました。 (以降、Java8で導入された日付時刻APIを単に「日付時刻API」と表します) もちろん、慣れてきて、ちょっとしたサポートメソッドを用意してやれば、結構使いやすいのですが、それは「このAPIは使いやすい」という評価にはなりません。 つまり日付時刻APIは、慣れないとぜんぜんわからないし、サポートメソッドがないと面倒なコードが必要ということです。 いろいろあってよくわからない 日付時刻では、時点を扱うInstantや期間を扱うPeriod、時間量をあらわすDurationなど多くのクラス・インタフェースが導入されています。 これらは、IDEの補完でAPIを探りながら機能を推測すれば、それなりにドキュメントなし

ちょっとまとめ。 ドメイン駆動設計・開発の実践 Eric EvansがDDD（ドメイン駆動設計）を語る Domain-Driven Designのエッセンス -目次- ドメイン駆動設計 ( DDD ) をやってみよう DDD時代の設計 - DDD-memo エリック・エヴァンスのドメイン駆動設計 (IT Architects’Archive ソフトウェア開発の実践) 作者: エリック・エヴァンス,今関剛,和智右桂,牧野祐子出版社/メーカー: 翔泳社発売日: 2011/04/09メディア: 大型本購入: 19人 クリック: 1,360回この商品を含むブログ (131件) を見る エンタープライズ アプリケーションアーキテクチャパターン (Object Oriented SELECTION) 作者: マーチン・ファウラー,長瀬嘉秀,株式会社テクノロジックアート出版社/メーカー: 翔泳社発売日:

さて、Java8で関数型っぽいことをやって遊んでみたわけですが、実際はそんな書き方しませんよね。 Java8で実際に使うのは、Streamです。 ということで、Streamの使い方をひととおり見てみます。 ※5/17 仕様変更があったので、修正しました 基本 まずは、Iterableインタフェースに用意されたforEachメソッドを見てみましょう。 List<String> names = Arrays.asList("hoge hoge", "foo bar", "naoki", "kishida"); names.forEach(s -> System.out.println(s)); これで次のように表示されます。 hoge hoge foo bar naoki kishida いままでの拡張forだと次のように書いてました List<String> names = Arrays.a

やあ、３月に延期になったとはいえ、Java 8リリースが具体化してきましたね。 もうこれで、Lambdaがはずれるとかいうことはなさそうです。 ところで、Java 8で関数型っぽいことができるようになってうれしいのですが、ちょっと記述が冗長です。ということで、短く書けるおまじない考えてみました。 Function型 さて、まずはJava 8で標準で入ったFunction型をみてみましょう。パッケージ名まで含めるとjava.util.funciton.Functionです。 こんな感じで使います。 Function<String, String> enclose = s -> "[" + s + "]"; Genericsでの型指定の最初が引数、あとが戻り値の型です。ここではStringをとってStringを返す関数としてencloseを定義しています。 これを呼び出そうとすると、こんな感じ

特に学術的にソフトウェア工学に触れたことはないのですが、むしろそうではなく現場にいる身としては、ソフトウェア工学は失敗しているように見えます。 「成功していない」ように見えるのではなく「失敗している」ように見えるのです。 もちろん、いまソフトウェア開発で使う技法やツールなど、ソフトウェア工学の産物はたくさんあり、現在のソフトウェア開発がソフトウェア工学から生まれたもので支えられていることには間違いありません。 でも、そうやって築き上げてきたものが、1999年以降ガラガラと崩れて、そしてうまく再構築できていないように見えます。 1999年、なにがあったかというと、XPエクストリーム・プログラミング入門という本が発行されたのです。リンク先は2版ですが、日本語版でも初版は2000年12月になっています。 ここからソフトウェア工学がガラガラ崩れた気がしています。 では、ここまでソフトウェア工学がど

プログラマというのは、道具に慣れることが、実力があがることにならないのですよね。だから、勉強せず業務経験だけだとレベルが低いままということになってしまう。 Javaを10年さわり続けて、Strutsを5年さわり続けても、それだけでは、与えられた画面を手際よく作成できるようになるだけで、たとえばStrutsすらよりよく使えるようになるわけではなかったりする。 Javaにしても、「volatileってなんですか？」という問いに、まあ知らないのはしかたないとしても、解説を見ながらですら答えられない可能性がある。 プログラムの反復生産は、プログラミング能力の向上にあまりつながらない。設定や記述に慣れるだけだ。そして、この「慣れ」というのには「難しいからそもそも実装を回避する」というようなものも含まれる。実力の向上は、作業ができるレベルで止まってしまう。 プログラマとしての実力をあげるための勉強が自

Conrad Irwinさんの「MVC is dead, it's time to MOVE on.」を訳してみました。 MVC is dead, it's time to MOVE on. この訳文も原文のライセンスを引き継いでCC-BY-3.0ライセンスで利用可能とします。 追記13:58 すでに訳してた方がいました。MVCの時代は終わった。MOVEを使い始めましょう。 - ふじこのプログラミング奮闘記 MVCは死んだ。MOVEするときがきた MVCはすばらしいアイデアだ。モデルを持ち、モデルは内部に少しの状態をもつ。ビューは内部に少しのUIをもつ。そして、コントローラは内部に少しの・・・ 何を持つ？ 私は確かにこのことに気づいた最初の人物ではない。しかし示されたようなMVCの問題のために、あなたは最後には過剰なコードをコントローラに詰め込むことになる。なぜなら、他にどこに入れていいか

ソフトウェアの見える化とか、暗黙知の形式化とかが流行ってるので、それに対するぼくの意見を。 ソフトウェアの見える化に関しては、暗黙知の形式化的な部分について。 ぼくの考え方は、暗黙知を暗黙知のまま伝達するのが理想で、それが無理だから形式化するという考え方です。 ソフトウェアも、見ないでうまくいくなら最後まで見ないように。 箱を開けるとシュレティンガーの猫が死んでいるかもしれない。 形式化というのは伝達の手段で、組織やプロジェクトをまわすための情報は、あくまでも暗黙知として人の中に存在するべきだと思うわけです。 暗黙知というのは、無限の組み合わせを持ったあらゆる可能性に対処できる情報です。 暗黙知を形式化するというのは、暗黙知の持っていた情報を、ある視点からいくつかの可能性に対して抜き出すことです。 ここで問題になるのは、そのとき抜き出されなかった可能性や別の視点での捉え方は、形式化した時点