Abstract Factoryパターン と Builderパターンの違い
GoFデザインパターンはなかなか奥深く、入門書を読んでパターンごとのクラスの絡み合いを理解しただけでは 真価を理解できないことが多々あります。 独習デザインパターン のクラス図からAbstract Factoryパターン と Builderパターンの違いがうまく説明できなかったので GoF本を紐解いて その目的を調べてみました。 Abstract Factoryパターンの適用可能性 Abstract Factoryでは、「ある抽象的な型の実装を返す」というインターフェースを定義し、 そのインターフェースの実装を多種揃えるといった形になります。 GoF本では例としてlook&feelを取り上げています。 JavaのswingのライブラリではUIのデザインをごっそり切り替えることができますが、 その具象クラスの生成を具象型を知らずに行いたいというようなケースを想定すればよいのでしょう。 GoF
[C++]Boost.Bind & Boost.Function
C++ で、似たような処理だけれども関数の引数の数や型が違うせいでその処理をひとまとめにすることが出来ない、ということがあったりしませんか？ 自分はよくありました。例えば以下のようなコードです。 // Hoge::FuncA の合計を返す。 // ただし Hoge::FuncA の結果がマイナスだった場合は // その時点での合計を返す。 int FuncA(Array<Hoge*> array, int a, int b) { int count = 0; for (int i = 0; i < array.length(); i++) { int result = array[i]->FuncA(a, b); if (result < 0) { break; } count += result; } return count; } // Hoge::FuncB の合計を返す。 // た
Ruby で getter, setter
さて、カプセル化でおなじみの getter, setter ですが。 Java ならこうですね。 private int _field1; private int _field2; private int _field3; public int getField1() { return _field1; } public void setField1(int field1) { _field1 = field1; } public int getField2() { return _field2; } public void setField2(int field2) { _field2 = field2; } public int getField3() { return _field3 } public void setField3(int field3) { _field3 = fi
イレイジャではジェネリクスの何が消えるのか
Javaのジェネリクスはコンパイル時に解決され、classファイルになった時にはジェネリクスの型情報は残されていません。そのためイレイジャ（型消去：type erasure）方式と呼ばれます。 と、ひとくちで言っても意味がよく分からないのでちょっと掘り下げてみましょう。 インスタンスからジェネリクスの型情報は拾えない リフレクションを用いたとしても、インスタンスからジェネリクス型パラメータが何であるかを取得することはできません。 List<String> stringList = new ArrayList<String>(); のような変数stringListがあったとして、ここから<String>を取得するということができないのです。これが消えてしまった部分。 この変数stringListに対する各種操作において、その型の安全はコンパイル時に精査され、 実行時にはあくまでObject型
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
