Builderパターン 個人的にBuilderパターンはオブジェクトの生成制御や、ものによっては可読性が高くて好きなパターンなんですが、その実装には用途によっていくつかパターンがあるので、まとめてみました。 生成するオブジェクトの条件 クラス名:People フィールド:String name(必須), Integer age(必須), String hobby(オプション) 必須要素はnullを禁止 PeopleクラスはStringを返り値とするhelloメソッドを持つ 今回はBuilderパターンの比較のため、パターン上必要でない限りgetterなどのメソッドは省略 Native Builder Builderパターンではなく、ただのコンストラクタ。Builderパターンを使いたくなるのはこれをやりたくないからだけど、比較のために記載。 class People { private S
In software engineering, the initialization-on-demand holder (design pattern) idiom is a lazy-loaded singleton. In all versions of Java, the idiom enables a safe, highly concurrent lazy initialization of static fields with good performance.[1][2] public class Something { private Something() {} private static class LazyHolder { static final Something INSTANCE = new Something(); } public static Some
今朝 Twitter で Visitor パターンによるダブルディスパッチの話題を見かけたので、そういや昔 Java でちろっと使ったことあったなーとどんなんだったか思い出してみました。 要件 確かこんなのを表現したかったんです。業務アプリでよくありがちな、業務実行可否判定ですね。実際にはもっとパターンが多くなると思います。 業務 エライ人 ヒラ 申請 不可 可 承認 可 不可 実装 とりあえずベタに書くとこんなんでしょうか。 // 役割 public enum Role { エライ, ヒラ; } // 業務 public interface Work { boolean isExecutableBy(Role role); } 業務を実装するとこんな感じ。 // 申請 public class Request implements Work { @Override public bool
You can find an overview of a lot of design patterns in Wikipedia. It also mentions which patterns are mentioned by GoF. I'll sum them up here and try to assign as many pattern implementations as possible, found in both the Java SE and Java EE APIs. Creational patterns Abstract factory (recognizeable by creational methods returning the factory itself which in turn can be used to create another abs
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Singleton in Java – the proper way « Electrotek
