ジェネリクスによるVisitorパターン拡張の考察 - プログラマーの脳みそ
先日twitterで "Expression Problem" という問題を知った。 静的な型付けの下で、場合分けのデータ構造に対して、新しい場合分けとその場合に対する新しい処理を、元のソースコードに手を加えることなく拡張定義すること 2009-05-16 この問題が意図するところを語るにはまずオブジェクト指向から流れを辿らねばなるまい。 オブジェクト指向のポリモーフィズム Javaのようなオブジェクト指向の言語で、ある特定のメソッドがあることを抽象クラスHogeで保証するとしよう。 public interface Hoge { void hoge(); } このとき、機能性、つまりメソッドというのは増えることがない固定のものだが、継承して実装されたクラスというのは自由に増やすことができる。そして、抽象型Hogeを扱っている既存コードは修正する必要がない。 これはいわゆる開放/閉鎖原則(
コードウォッチ：関数型プログラミングの自惚れ問題
僕は関数型プログラミングが好きだ。次の10年にかけてコードの革命を起こしていくだろうと考えている：言語はより関数型の機能を採用していくだろうし、開発者はより関数型の技術を導入していくだろうし、いくつかの点では、関数型プログラミングの原則はコードを組み立てていく上で「自然で」もっとも明確なやり方だとみんな考えるようになっていくだろう。 だけど、僕はもうこのシナリオを本気にしちゃいない。関数型プログラミングは、ワクワクするものを学ぶことに興味があると言っている主流のプログラマにとって明白な、大きな問題を抱えている：関数型プログラマーは自惚れ野郎どもだってことだ。 モナドって何？「モナドは自己函手の圏における単なるモノイドに過ぎないよ！(ｷﾘｯ ヒャッハー、そんな単語も何一つ分かってないとか、君、おバカな主流プログラマーってやつじゃないかい？m9(＾Д＾)」 実用的なシステムを構築するのに役に立
「MVVMパターンが必要な理由」啓蒙用資料公開 - the sea of fertility
MVVMパターン的な実装は、他のプラットフォームでは選択肢の一つにすぎませんが、WPF/Silverlight(Windows Phone 7 含む)においては唯一の選択肢です。コードビハインドを書かないことはMVVMパターンそのものの定義とは関係ありません。まずはスキルにあったレベルでMVVMパターンを意識した実装を初めてみませんか？ 以前の勉強会発表資料（わんくま勉強会での発表資料の半分以上をカットし、Androidテスト祭り分追加）を加工し、社内勉強会、そのほかの勉強会・ブログなどで自由に使える資料として公開します。私の個人名は抜いてあります。 無許可の改変・引用なども問題ありません。ただ、資料の直接の商用利用などはご遠慮ください。 ブログに張り付けたい場合、下のbマークから埋め込み用URLを取得できます。 「コードビハインドを書くのはMVVMパターンではない」などの誤解が、MVVM
サバクラ両方で動く JavaScript の大規模開発を行うために
サバクラ両方で動く JavaScript の大規模開発を行うために 原文：Scaling Isomorphic Javascript Code (This is just for study, please contact me at tily05 atmark gmail.com if any problem.) 考えてみれば Model-View-Controller とか MVC ってよく聞くよね。実際どんなものか知ってる？ 抽象的に言うなら「オブジェクト情報の保持されるグラフィック・システム (つまり、ラスターではないグラフィック。ゲームとか) 上に構築された、表示系を中心としたアプリケーションにおいて、主要な機能どうしの関わりをうまく分離すること」とでも言おうか。もう少し深く考えを押し進めてみれば、これは当然、他のさまざまなアプリケーションにもあてはまる言葉 (bucket te
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
