設計
Googleグループのobject-compositionグループではDCIアーキテクチャに関する議論がなされている様です。 その中でC#によるDCIアーキテクチャの実装についてはやはり「拡張メソッドを使ったtraitあるいはミックスイン（mixin）的なもの（その３） - Jamzzの日…
Coplien氏とMartin氏の「Coplien氏とMartin氏、TDDとCDDそしてプロフェッショナルの定義について大いに語る。」の議論はとても面白いです。 二人の議論は平行線の様に見えますが実際の問題意識は共通しているように思います。 ただMartin氏の方が業界への期…
自分の理解を確認するために拡張メソッドの活用について整理したいと思います。 拡張メソッドの活用例として特定のクラスを通じて取得するSingletonというものを考えてみました。 通常Singletonは利用する側が任意の個所で取得するようになっていると思いま…
昨日「拡張メソッドを使ったtraitあるいはミックスイン（mixin）的なもの（その２） - Jamzzの日々」の最初の投稿した後にお風呂に入ってあれこれ考えていたらメモリリークに気がついて、ひょっとして参考にする人がいるかもしれないと思って取り急ぎソース…
ここのところtraitに惑わされてだいぶ寄り道して凝った内容を書いてしまったのですが、個人的にはミックスイン（mixin）的に型階層に関係なくスコープを限定して後付けで機能を追加できればそれで充分に嬉しいと思っています。 C#の拡張メソッドはまさにその…
「拡張メソッドを使ったtraitあるいはミックスイン（mixin）的なもの（その１） - Jamzzの日々」に引き続いて、「第4回 Scala言語を探検する（2）（2ページ目） | 日経 xTECH（クロステック）」にある「Traitでアスペクト指向を簡易に実現」の例をC#で実現し…
「C#クックブック 第3版」をパラパラと見ていて拡張メソッドというものがあることを知りました。 これは使えそうだと思っていたところにScalaにはTraitsというものがあってこれが多重継承あるいはミックスイン（mixin）と同様に活用できるということで注目を…
経営もプログラマもやっていて、バタバタしていて気がつけばもう2週間も前のことのなのですがAsianPLoP 2010に参加しました。 そこで得たことはたくさんあるのですがその中でも大きい点はパターン、あるいはパターン技術というものに対する認識が変わったこ…
引き続きCode Contractsを使用した仕様記述と検証についてです。 試しに鶴亀算について仕様記述と検証を行ってみました。 はじめは簡単に考えていたのですが実際にやってみるとなかなか奥が深く思っていたほど簡単ではないことが分かりました。 そしてこの難…
Code Contractsを使用した仕様記述の参考としてジャンケン判定の仕様記述の例をあげておきます。 public enum Gesture { Rock, Scissors, Paper, } public enum Winner { Player1, Player2, Draw, } public class ScissorsPaperRock { public Winner Judge(G…
「Code Contracts（契約）の使いどころ - Jamzzの日々」に引き続きCode Contractsについて書きたいと思います。 ここまでの内容はソフトウェア本来の目的である仕様の実現という視点で品質と生産性を向上させるためにCode Contractsを契約による設計（DbC:De…
「Code ContractsとPex - Jamzzの日々」に引き続いてCode Contracts（契約）の使いどころについて書きたいと思います。 Code Contractsで興味深いと思う点は契約の継承、特にインターフェイスやabstractのクラス（abstractのメソッド）に対する契約を記述で…
マイクロソフトのDevLabsで公開されている.NETにおける設計とテストにおけるテクノロジーであるCode ContractsとPexを使ってみました。 結論から言うとかなり使えそうでひょっとしたら開発スタイルを変え可能性があると思いました。 かなり奥が深そうでまだ…
プログラミング言語についてそれほど明るいわけではありませんがC#やScala、F#等のモダンなプログラミング言語の動向を見ていると、手続き型であるオブジェクト指向パラダイムと宣言型パラダイムの融合が進んできていて、徐々に慎重にであはりますが、さらに…
Martin Fowler's BlikiでWard Cunninghamが作ったメタファーである「技術的負債」は結構使えるというコラムがあります。 http://capsctrl.que.jp/kdmsnr/wiki/bliki/?TechnicalDebt その考えを借用してソフトウェア設計資産のバランスシートというものを考え…
「見える化」の重要性が叫ばれて久しいですがさまざまな取り組みの状況を見ていると、「見える化」のための報告や情報管理でコストや手間が増大することにより合理性がなくなったり、挙句の果ては「見えるだけ化」だったりして効果的・継続的な実践は難しい…
私がC#を初めて使うことになった以前の案件では.NET Framework 2.0を使っていました。 その時からC#をかなり気に入っていたのですが最近またC#を使う機会を得て最新の.NET Frameworkに触れるようになってますます気に入りました。 特にラムダ式がクロージャ…
以前（ってもう一年以上前！）にクロージャについて書きましたが仕事ではクロージャをサポートする言語を全く使わないこともあって設計に使用することがありませんでした。 最近MATLABを使用する機会があって初めて本格的にクロージャをサポートする言語で実…
インターフェイスとは使う側と使われる側のコミュニケーションの接点である。 コミュニケーションは片方だけの問題ではなくて相互の関係によって成り立つものである。 相互の関係が洗練されればインターフェイスも洗練されたものになると思う。
ソフトウェアで問題のある動作や意味が理解できない動作について設計者に質問したときにプログラムのロジックを詳しく説明してくれることがよくあります。 私としては設計者自身がどういう意図を持っていてその動作が設計者の意図通りかどうかを確認したくて…
私が今まで関わったプロジェクト環境における開発プロセスのあり方についてある程度自分の中で形が作られつつある中で最近より強く課題と感じられることに要求仕様の管理があります。 典型的には要求を明確にして要求仕様書（ドキュメント）を書くということ…
最近ふと、関西人はオブジェクト指向分析・設計に向いているのではないかと思いました。 関西弁では飴を「飴ちゃん」と言ったり芋のことを「お芋さん」と言ったり人ではない物に対して「ちゃん」や「さん」などをつけることが良くあると思います。 このよう…
最近、経験が少ない技術者育成のガイドに使えるような書籍を探しています。 そんなわけで候補のひとつとして「CODE COMPLETE 第2版 上 完全なプログラミングを目指して」を読んでいます。 いろいろな人とお話していると一般的には私が思う以上にプログラミン…
建前としてソフトウェア設計としてどうあるべきかはプロジェクトマネージメントのやり方や内容と無関係であると言いたいところですが、現実的にはプロジェクトの体制やマネージメントのやり方がソフトウェア設計に影響することは否定できないと思います。 そ…
条件を判断（分岐）しながら実行処理を実行するようなコードは人が読んで理解しにくいだけでなく将来のバグの温床になる可能性が高いので、可能な限り条件判断のロジックと判断の結果の実行処理のロジックを分離する構造にする方が良いです。 条件判断と実行…
一般にはリッチクライアントはユーザエクペリエンス（ユーザ体験）やユーザビリティの観点で語られることが多いですが、MVCモデルにおけるビューの観点でも無視できないと思います。 リッチクライアントではリッチなユーザエクペリエンスを実現すると同時に…
私はごく最近までクロージャという言葉を知りませんでした。 またその存在を意識したこともありませんでした。 クロージャという言葉を知ってからはいろいろなところでその言葉に出会うことに気づき、最近流行っているのかなと思いました。 インターネット上…
一般的にソフトウェア設計における記法やパターンを学ぶ理由は設計技術の習得だと思います。 もちろんその通りなのですが、それだけではない重要な理由があると思っています。 それはソフトウェア技術者同士の設計に関するコミュニケーションのためです。 ソ…
なぜRubyでクリップボードを使おうと思ったのかといえば、開発の補助的にRubyを使うときに任意のアプリケーションとテキストのやり取りが行えると良いと思ったからです。 例えばVisualStudioやeclipseなどのエディタ開発しているC言語のソースの一部をクリッ…
音楽理論の知識が無くても作曲や編曲を行うことはできるでしょうか？ 答えは感性とちょっとしたツールを使えるテクニックがあれば可能です。 実際に音楽理論はおろか、楽器も引けないプロのミュージシャンの方がいらっしゃいます。 それでは音楽理論というも…
