オブジェクト指向の本では「自転車をモデリングしてみましょう」「鳥をモデリングしてみましょう」ということが、どういうシステムで使うか規定せずによく書かれています。 けれども、モデリングではどういうシステムで使うかということが大事で、それを決めずにモデリングを考えても意味がありません。モデリングすべきはモノではなくシステムのプロセスです。 よく、オブジェクト指向では現実をモデリングするのようなことが言われますね。 例えば鳥が鳴くとして、その一種であるニワトリをどうモデリングするか、ということを考えるとします。 そうすると、まず void 鳴く() { print("コケコッコー"); } のようなメソッドを考えるのですけど、コケコッコーとうまく鳴けるのは鳴き慣れたニワトリです。そのため、鳴くメソッドにカウンターを用意してどんどんうまくコケコッコーになるようにしたくなります。 いや、そもそも、コ

「オブジェクト指向するとプログラムが読めなくなるから禁止」のような話は昔からあって、新しい技術についてこれない人を揶揄するようなニュアンスで使われていましたが、実際にはこれはオブジェクト指向迷路にうんざりした現場での率直な意見だと思います。 オブジェクト指向は、まじめにやるほどプログラムを読みにくくするという性質をもっています。 ※ 使い方次第というコメントついてますが、だからこそちゃんと性質をしっておく必要があると思います。 オブジェクト指向の代表的な指針を３つあげると次のようなものがあります。 オブジェクト同士の連携としてプログラムを組む 単一責務の原則 インタフェースと実装の分離 まず、オブジェクト同士の連携でプログラムを組むと、コードが飛びまくって追いにくくなります。そして単一責務の原則により、小さいクラスが大量に生成されて、追いにくさがさらにあがっていきます。 ダイクストラ先生が

Optionalは意図的にSerializableではなくなってますね。 でその意図としては、一旦Serializableにして出力形式を決めてしまうと、今後ずっとその出力形式を維持しないといけないことになるので、そのメンテナンスコストを嫌ったというのがあるようです。 このメンテナンスコストの中には、仕様が変えれなくなる、というコストも含みます。 なので、シリアライズしたい場合には、フィールドはnullを持つようにして、getterでOptionalに変換するということになると思います。 基本的にOptionalは、Optional-returnイディオムをサポートするもの以上ではない、ということをBrian goetzさんも書いています。 Shouldn't Optional be Serializable? そこで、Optionalの使い方としては、基本的にメソッドの戻り値としてだけ、

おととい、渋谷JVMというイベントがあって登壇させてもらったんですが、そのあとビール飲んでるときに、ぼくが「コード書く前にコメントだけ書くのいいよね」と言ったあとの返答としてきょんくん(kyon_mm)が言った言葉。 全体としては 「コード先に書いてそのコードに対してテストを書くと実装に対するテストになるし、コードを先に書いてそのコードに対してコメントを書くと実装に対するコメントになる」 という感じ。 ここに至るまでの話もおもしろかったんだけど、ここでは、コメントについて書いてみます。 まず、実装に対するコメントってどういうのかというと、こういうの。 id = findId(name); if(id == -1){ // idが-1だったとき登録 register(name); } いやそれはコード見ればわかるから、ってやつですね。 これは、こうやるとより適切です。 id = findId

ちょっと気になったので、簡単にベンチマークしてみました。 最初は、ラムダ呼び出しが入る分forEachは遅いんじゃないかと思っていたら、倍の速さに。 もちろん、いろんな条件で変わるんだろうけど、ここまで差が出ることがあるのは驚き。 あと、Collectors.summingIntのような基本型に対するCollectorを使うよりは、intStreamに変換してからsumなど専用メソッドを使うほうが圧倒的に速いことも確認できた。 とりあえず、0から10万件のListを用意。 array = IntStream.range(0, 100_000).boxed().collect(Collectors.toList()); それからベンチマーク用のメソッドを用意。 public static void bench(String name, Supplier<Integer> proc){ ben

Java8では、関数型インタフェースへの値として引数が揃ったメソッドの呼び出しを単純に渡す場合に、ラムダの形でもメソッド参照の形でも書くことができます。 このときの書き分けの基準を考えてみます。 つまり、 public void actionPerformed(ActionEvent ae) { System.out.println("押された"); } のようなメソッドがある場合に JButton b; b.addActionListener(ae -> actionPerformed(ae));//ラムダ と書くか、 JButton b; b.addActionListener(this::actionPerformed);//メソッド参照 と書くかという話です。 まず、この例のactionPerformedメソッドのように、関数型インタフェースに渡すことが前提で定義されたメソッドのよ

Javaプログラマのみなさんは、Javaは型推論がないから変数の型指定をしなくていけなくてダサい、などとイジメられた経験があると思います。 おかあさんに型推論をねだるとGroovyをわたされたり、おとうさんに型推論をねだるとScalaがやってきたり、プレステが欲しいって言ったのにWiiやXboxを買い渡される感を味わった人も多いのではないでしょうか。 そんな良い子のJavaプログラマのために、今年はサンタが素敵なプレゼントを持ってきてくれましたよ。 同じ型を書くのがダサい たとえばウィンドウを出してボタンを押したらメッセージが表示されるサンプルを書くとこんな感じになりますね。 public static void main(String... args){ JFrame f = new JFrame("テスト"); JButton b = new JButton("押して"); JText

Javaに限った話ではないのだけど、Javaで並列加算が気軽にできるようになったので、気に留めておいたほうがいい話。 まず、次のようなコードを動かしてみます。 public static void main(String[] args){ double[] data = { 1.234E80, -1.234E80, 2, 3}; System.out.println(Arrays.stream(data).sum()); System.out.println(Arrays.stream(data).parallel().sum()); } 1.234×10^80と-1.234×10^80という、桁が大きくて符号の違う数を並べて、そのあとに2と3という1桁の数値を置いています。 これらを加算すると、1.234×10^80と-1.234×10^80は符号が違うだけなので、当然結果は0になります

昨日のOSC福岡2013の「勉強会x勉強会」セッションで飛び込みLTしたときのプレゼンに加筆して公開しました。 追記：福岡の人はFacebookの福岡IT関連勉強会に参加しておくと、勉強会情報が得やすいと思います。

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

FPGAでCPUを組んでると、フェッチ部やデコーダ部で足し算や掛け算をしようとして、そんなことしたらCPUの意味ないなーと思ってしまうことがありました。 で、よく考えたら、FPGAでロジックを組むならCPUの意味はないんです。 だいたい、ひとつの処理実行するのに何クロックかかってんですか！と。 CPUでは、計算効率をよくするためにパイプラインという仕組みが使われています。 最近では、18段とかのパイプラインもあるようです。 ここで、18段のパイプラインのうち、実際に計算を行うのは2段か3段だったりします。残りの15段くらいは、命令や計算結果を読んだり書いたりしているだけです。 このパイプラインも、ほとんどはメモリの読み書き、それも命令の読み込みに多くが使われます。 であれば、CPUにしなければ、18段全部計算に使えるんじゃね？という話になりますね。 決まりきった計算を行うのに、いちいちメモ