FizzBuzz ループ→再帰→Composite→Strategy→Visitor - プログラマーの脳みそ
最近FizzBuzzをblogで書くといいよみたいな流れになっている(曲解)ので FizzBuzz - 文殊堂 と id:monjudoh が言ったからというわけではないのだけど、FizzBuzzとアルゴリズムの書き換えの話をしよう。 やや昔のエントリになるけどもJavaでFizzBuzzを再帰で作ったというエントリをみつけた。 public class FizzBazzSaiki{ public static void main(String[] args){ System.out.println(func(args.length>0?Integer.parseInt(args[0]):30)); } public static String func(int i){ if(i == 1) return "1"; System.out.println(func(i-1)); return
Undo,Redoの実装つづき - あしあと日記
いや、悪い反応では無いのでむしろ喜ぶべきことなんだけど、意外と好評なエントリーなので続きを書きます。 タイトルだけは前回同様釣りっぽいタイトルで＾＾ 前回のエントリーが思ったより反響が大きくてびっくりしてます。なんか炎上してるのか？って思っちゃいましたｗ 炎上っていうのはさすがにネガティブだし、内容とかけ離れすぎてるのでタイトル変えました。 さて前回はコマンドパターンとコマンドの実装について書きましたが、今回は予告どおり実行部の実装についてです。 といっても、今回はとっても単純な話です。Undo用にスタックにコマンドを積んで、Undoするよって呼ばれたら、スタックからコマンドをpopしてきてundoの処理を実行するだけです。 ただし、Redoも出来ないと行けないので、実行したコマンドは今度はRedo用のスタックに積んでいきます。 実装は次のようになります。 まず前回の二番目のパターンに則っ
Undo,Redoの実装って何十回もやってる気がする - あしあと日記
undo,redoの実装って何十回もやってる気がする。毎回同じパターンだ。undo,redoが登場するような編集ソフトは大体同じパターンに落とせる。フレームワークも作った。ブログにそういう内容を書きたいが面倒くさい。需要があれば面倒でも書くんだけどなあ http://twitter.com/youpychan/status/994486992 という発言をしたら何人か反応を頂いたので書いてみることにする。 需要があるなら書こう。undo,redoだけじゃなくてグラフィカルな編集ソフト全般の話をいつかまとめたいと思っていたので、ちょいとシリーズで書いてみようかとおもう http://twitter.com/youpychan/status/994636764 書こうと思う。 まずUndo,Redoについて。 Unod,Redoってみなさんどういう風に実装しているでしょうか？ 私はコマンドパタ
Inversion of Control コンテナと Dependency Injection パターン
以下の文章は、Martin Fowler の「Inversion of Control Containers and the Dependency Injection pattern」を、かくたにが翻訳したものです。原著者の許可を得て翻訳・公開しています。 翻訳にあたっては、kdmsnr さんにご協力をいただきました。ありがとうございます。公開後の改訂履歴を記事の最後に記述しています。 Java コミュニティでは軽量コンテナが花盛りである。 軽量コンテナは、異なるプロジェクトのコンポーネントをひとまとまりのアプリケーションとして組み立てることを支援する。 このようなコンテナの根底には、コンポーネントの結び付け方についての共通したパターンがある。 そのパターンのコンセプトは「Inversion of Control(制御の反転)」と、まことに包括的な名前で呼ばれている。 本記事では、このパタ
DAOパターンのデメリットを補う「DataAccessMethodパターン」：CodeZine
はじめに CJ2EEのDataAccessObjectパターンは、企業向けシステム開発で利用される非常に優れたデザインパターンです。これを利用することにより、柔軟なシステムを構築することが可能となります。有名なパターンなので、多くの方はこのパターンを使った設計／開発に携わった経験があるのではないかと思います。 しかし、DataAccessObjectパターンを使った開発は多くのクラスやインターフェイスを定義する必要があります。これは、DataAccessObjectパターンがAbstructFactoryパターンをベースとしているためです。クラスやインターフェイスの数が増えると開発コストだけでなく管理コストも増大し、開発規模が大きくなるほど影響が大きくなります。 本稿では、こうしたDataAccessObjectパターンのデメリットを回避するためのパターンを紹介します。対象読者企業システム
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
デザパタ140文字
組織のデザインパターン － tknakamuraの日記
IBM Developer