Rubyのmixin(モジュール)、Squeakのtrait、Scalaのtraitそれぞれについて： Q1: メソッドの実装を持てる？ はい、はい、はい Javaのクラスは「はい」、インターフェイスは「いいえ」、C++とPythonのクラスは「はい」 Q2: クラスがそれを複数個継承できる？ はい、はい、はい Javaのクラスは「いいえ」、インターフェイスは「はい」、C++とPythonのクラスは「はい」 Q3: インスタンスを作れる？ いいえ、はい、いいえ C++とPythonのクラスは「はい」 Q4: 複数個継承した際に名前が衝突しました、どうなる？ しれっと上書き、エラー(*)、エラー (*) Squeakはクラス定義時には例外を投げず、衝突したメソッドを「衝突した旨の例外を投げるメソッド」に置き換える。ユーザが衝突に気づくのは、クラスブラウザでメソッドを確認した時か、そのメソッド
OOP と RDB の「インピーダンスミスマッチ」議論の起源を探ろうと調べ始めたら、有用な情報を頂いたのでまとめます。 このリストは誰でも編集可にしておきますので、情報がございましたら自由に追加/編集してください。
先日書いたstaticおじさん達に伝えたい、手続き指向とオブジェクト指向の再利用の考え方の違いについて - 達人プログラマーを目指してのエントリに、なんと、みながわけんじ氏ご本人よりコメントを頂きました。もともとは一般のstaticおじさん達（英語ではstatic ojisansという感じ）に向けて書いたのですが、思いがけず、元祖staticおじさん（The static ojisanあるいはMister staticといった感じ)ご本人からのご意見をいただき、本当に嬉しく思います。 オブジェクト指向の再利用性と非オブジェクト指向の関数やサブルーチンとの違いを明確に示していないから いろいろ理屈を込めても無駄ではないでしょうか？ 誰かが作ったクラスを継承して再利用したところで、バグが少なくて、メンテナンス性がいいものができるでしょうか？ そんなものをあてにするより、天才が作ったクラスライブ
一般的な業務アプリケーションではデータを永続化するために、RDBMS（関係データベース管理システム）を利用します。RDBMSでは大量のデータを効率的に検索したり、集約してレポートを作ったりすることが得意ですし、一般的に業務システムで求められるトランザクションのACID特性*1を満たすことも容易です。また、適切にテーブル設計の正規化を行うことにより、運用面においてデータの管理コストを下げることもできます。最近ではスケーラビリティの問題などもあり、RDBMS以外のデータベースについても注目されるようになってきていますが、今後も業務アプリケーションの主流としてRDBMSは使われていくだろうと思われます。 従って、Javaなどのオブジェクト指向言語で開発を行い、DDDのようなオブジェクト指向の設計技法を利用する場合に必ず考えなくてはならない問題は、オブジェクト指向と関係モデルとのインピーダンスダン
UML::Class::Simple ってモジュールがあります。このモジュールを使うと既存のプログラムを解析してクラス図を作成することができます。業務で仕様書を書く必要がでた場合、もしくは Catalyst のようなフレームワークをより深く知りたくなったときなどに大いに役立つモジュールです。 http://search.cpan.org/~agent/UML-Class-Simple/lib/UML/Class/Simple.pm UML::Class::Simple is a Perl CPAN module that generates UML class diagrams (PNG format, GIF format, XMI format, or dot source) automatically from Perl 5 source or Perl 5 runtime. Per
ここに掲載したコードは、『増補改訂版Java言語で学ぶデザインパターン入門 / 結城 浩(著)』に掲載されているサンプルコードをC#に移植したものです。 ブログ「Gushwell's C# Dev Notes」に掲載していましたが、多くのブログ記事の中に埋もれてしまっているので、こちらに引っ越すことにしました。なお、ブログに掲載したソースは、原書のソースコードにできるだけ忠実にC#に移植することを心がけましたが、こちらに引っ越す際に、C#2.0, C#3.0の練習も兼ね、すべてのソースに見直しをかけています。どうでもいいところで、LINQを使ったり、ジェネリックスを使ったりしていますが、そこは笑って許してください。 ただ、デザインパターンの本質部分は、C#の特徴を出しつつ、原書の設計を踏襲しているつもりです。 C#のソースファイル（プロジェクトファイル）もダウンロードできるようにしています
Java におけるコード進化パターン (Code Evolution Patterns in Java) asato shimotaki <asatohan at gmail.com> 最終更新日 : 2009/6/21 (2004/4/22 より) [...] For twenty years, I spent two or three hours a day looking at pairs of things -- buildings, tiles, stones, windows, carpets, figures, carvings of flowers, paths, seats, funiture, streets, paintings, fountains, doorways, arches, friezes -- comparing them, and asking my
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
