再考: GoF デザインパターン - Qiita
本投稿は私の主観によって書かれています。コメントは大歓迎です。もし長くなるようでしたら別途記事に投稿し、リンクを張っていただけると嬉しいです。 概要 GoFのデザインパターンは適当すぎるから、いい加減、修正されるべき。 参考までに各パターンに対するコメントを書く。 GoFのデザインパターン GoFのデザインパターンは適当であり、教科書通りに学ぶべきものではないように思う。 以下がGoFのデザインパターンの良くない原因だろう。 本が出版されたのは1994年であり、Java(1995)が出てくるよりも前だった オブジェクト指向が未成熟な時代にカタログ化された 現代のプログラミングと合致しないものが多い 「オブジェクト指向における～」と断っている以上、OOPに絡める必要があった パターンのいくつかに「多態性を用いると便利」という蛇足がついている 挙げたパターンに根拠がない 「とりあえず、23個ほ
デザインパターンの骸骨たち
『デザインパターン』 うんちくできると、かっこよさそうだよね～。でもあんな分厚い本読んでもピンとこないし、だいたいオブジェクト指向ってなに？なにが便利なのかよく分からんのだけど。いいじゃんなんでも。できればいいんだよ、できれば。 な～んて、思っていても、なんとなく オブジェクト指向が気になっている システム開発者は、多いのではないでしょうか？かくいう 私もそんな者の一人でした。 しかし、これだけ もてはやされているオブジェクト指向です。 なんか、便利なはずです。 そこで、私は、ＧＯＦのデザインパターン[1]を、できるだけシンプルに表現した、小さな小さなプログラム ～デザインパターンの骸骨たち～ を作ってみました。骸骨達 を骨の髄までしゃぶり尽くつくすせば、オブジェクト指向の真髄まで味わうことができるかも。！？ 『デザインパターンの骸骨たち（RE-BONE）』 では、内容を大幅に見直し、Ja
リソースモデリングパターン
Webアプリケーションについて、RESTfulなURL・リソース設計のパターンを見出すことで、 どのパターンかを判断するだけで、既存の Good Practice が適用できる 名前をつけて呼べるようにしたい Railsなどのフレームワークで簡単に適用できるようにしたい ということを目指しています。 ほんとうに役立つか これはパターンと言えるのか もっと他にもある だいぶ粒度がバラバラ 名前の付け方（パターンは名前重要） など、ぜひご意見をください。 パターン Collection & Member Resource パターン Singular (Singleton) Resource パターン Filtered Collection パターン Filtered Subresource パターン Multi-member Resource パターン Partial Resource パター
Pythonでデザインパターン - モジログ
GitHub - faif / python-patterns https://github.com/faif/python-patterns GoFデザインパターンのPythonによるサンプルコードを集めたプロジェクト。以下の各ファイルが入っている。 - abstract_factory.py - adapter.py - borg.py - bridge.py - builder.py - chain.py - command.py - composite.py - decorator.py - facade.py - factory_method.py - flyweight.py - iterator.py - mediator.py - memento.py - null.py - observer.py - pool.py - prototype.py - proxy.py -
MVCは死んだ。MOVEするときがきた - きしだのHatena
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の問題のために、あなたは最後には過剰なコードをコントローラに詰め込むことになる。なぜなら、他にどこに入れていいか
デザインパターンを読み解く
ポリモーフィズム（サブクラスによる切り替え、抽象化） ここに分類されるのは、オブジェクト指向の第３原則、ポリモーフィズムを使用したパターンです。ポリモーフィズムを使用すると、動的に使用するクラスを切り替えることができます。＜参照＞ 他に分類されているものでも、ポリモーフィズムが重要な位置を占めているものもありますが、ここではそれしか使われていないものを扱います。 ただデザインパターン全体を通して強調されているのは、インターフェースでプログラミングするということです。実装への依存をなくし、そうすることによって設計の骨組みを明らかにするのです。 Template 次のようなメソッドがあった場合に、処理Bのところを条件によって変えたい場合があるとします。 class Hogehoge { void doit() { ... 処理A ... ... 処理B ... ... 処理C ... } }
GoFの23のデザインパターンを，Javaで活用するための一覧表 （パターンごとの要約コメント付き） - 主に言語とシステム開発に関して
GoFデザインパターンの一覧表と，活用のためのコメント，および入門者が独学するためのリンク集（サンプルコード付き）。 入門者の独学を支援するために，このページのURLを提示して熟読させ，各パターンを短時間で効率よく学んでもらう。 デザインパターンはプログラマの常識だ。 Java使いかどうかは問わない。 にも関わらず，入門書を買ったまま，途中で挫折する人が多い。 挫折の原因は，パターンの数が23もあって，多いからだろう。 全パターンをすんなり覚えてもらうためには，各パターンごとに 「要するにこういう目的のパターンなんだ。」 「10文字で表現すると，パターンの意味はこうなんだ。」 という要点・本質を，短いコメントで伝えれば助けになるだろう。 こういった学習を通して，Java言語の「設計思想」も併せて感じ取ってゆけるはず。 全パターンの一覧表（要約コメント付き） 全パターンについて，10文字以内
Android Action Bar をカスタマイズする
Android Developers Blog: Customizing the Action Bar Action Bar のデザインパターンを紹介してから、多くのアプリケーションが Action Bar を使うようになりました。 そして、このデザインパターンは Android 3.0 でデフォルトの機能になりました。 Honeycomb をターゲットとしたアプリで Action Bar を使う方法は using Action Bar を参照してください。 Theme.Holo.* を継承した独自スタイルを定義して、ここで Action Bar をカスタマイズしていきます。 <style name="Theme.MyTheme" parent="android:style/Theme.Holo.Light"> … </style> ■ Icon Android Asset Studio
俺が勝手に考える正しいMVCの実装。モデルはデータAPI！ - はかますたいる！きょろの技的雑記
最近、一緒にコードを書く人（特にRailsから始めた学生さん）に、 MVC（Model - View - Controller）において、「model = DB」だと考えている人が多いなぁと感じたので、このあたりに関する自分の考えをまとめて書いておきます。 あくまで俺の考えなので、違ってたらごめんね。 MVCをちゃんと理解している人には当たり前すぎる話かもなのでスルーでよろしく！ 初学者はViewをモリモリ生やす これはプログラミングを始めた人なら誰でも経験ありますよね。 むしろ、MVCとか始める前の、誰でも経験あるであろう <?php print '<a href="${hoge}">link</a>'; なんてのは完全にViewだけで実装されたプログラムですね。 最近のMVCのテンプレートはとても高機能です。 変数の宣言も、条件処理も、ループも、プログラム言語としてひと通りの「逐次、反
テスト可能なUI設計パターン – 第１回 Androidテスト祭り 発表資料 - the sea of fertility
2011/8/6 第１回 Androidテスト祭りの発表資料を公開します。.NETクラスタという先入観を持っていただきたくなかったので、自己紹介スライドは最後にさせていただきました。でも非常に空気のよい場だったのでそんな配慮は不要だったかもしれません。 反省点としてはやはり伝え方です。設計パターンに対する意識がすでにある方には届くみたいですが、あまり今まで意識していない方に、どうやって今後伝えていくべきか、きちんと今後考えていきたいと思います。 一応補足として、WPF/SilverlightでのPresentationModelパターンの実装パターン?であるMVVMパターンについて、どういった必然性がWPF/Silverlightにあるのかはこちらに書いてありますますので、興味を持っていただける方はどうぞ。 MVVMパターンとは？ わんくま同盟東京勉強会 #60 セッション資料 the
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
