Martin Fowler's Bliki in Japanese - 暗黙的インタフェースの実装
http://martinfowler.com/bliki/ImplicitInterfaceImplementation.html JavaもC#も純粋なインタフェース型というものを用意している。 純粋なインタフェースはinterface Mailableのように宣言し、 Javaの場合だとclass Customer implements Mailableのようにして実装する。 ひとつのクラスは複数のインタフェースを実装することができる。 このモデルが考慮していないのは、 クラスには必ず暗黙的なインタフェース(implicit interface)があるという点である。 Customerの暗黙的なインタフェースは、Customerで宣言されたすべてのpublicなメンバである（この暗黙的なインタフェースは、今まで私が見てきたどのOO言語にも存在する）。 JavaでもC#でも、暗黙的なイ
『Java並行処理プログラミング その「基盤」と「最新API」を究める（ブライアン・ゲーツ、ダグ・リーほか／岩谷 宏 訳）』 販売ページ
並行処理の基盤と最新APIを究める！ ｊava.util.concurrentを駆使した豊富なプログラムと親しみやすい解説文で、難解といわれるマルチスレッドプログラムを、安全でスケーラブルに書くために必要なコンセプトとテクニックが身につきます。 ▼目次 第1部：基礎編（スレッドセーフ、オブジェクトを共有する ほか） 第2部：並行アプリケーションの構造を作る（タスクの実行、キャンセルとシャットダウン ほか） 第3部：生存、実行性能、試験（生存事故を防ぐ、実行性能とスケーラビリティ ほか） 第4部：高度な話題（明示的なロック、カスタムシンクロナイザを構築する ほか） 付録A:並行処理のためのアノテーション
いまだに継承を使うタイミングが分からない - みずぴー日記
いまだに継承を使うタイミングが分からない。もうちょっと正確にいうと実装継承を使うべきタイミングが分からない。 インタフェースを継承するのは理解できるよ。型をそろえたり、同一視したいんでしょ。 よくあるコードだとこんな感じ。ちゃんと動くかどうかは知らない。 interface Foo { ... } class Bar implements Foo { ... } class Baz implements Foo { ... } List<Foo> foo = new List<Foo>(); foo.push(new Bar()); foo.push(new Baz()); でも、クラスを継承するのがよく分かんない。メソッドとかを再利用したいんなら、委譲を使ったほうが安心じゃん。不用意なメソッドを公開したりしないし。 class Foo { public void f() { ... }
無題ドキュメント
今回は、もっとも基本的であるわりには、意外と問題の多い「継承」について考えてみたいと思います． 型の拡張は、2つの機構を使って行われます．すなわち継承と総称です． 継承は下位型による多相性（Subtype Polymorphism）を実装し、総称はパラメータによる多相性（Parametric Polymorphism）を実装します． 継承は大きく型継承と実装継承（クラス継承）に分類できます．この場合、型とクラスの関係に注意が必要です． 型はオブジェクトのインターフェイス、すなわちオブジェクトの振る舞いの定義です．他方、クラスはオブジェクトの内部状態とオペレーションの実装を定義しています．クラスは同時に型を定義する場合もありますが、言語によっては必ずしもそうとは言い切れません． 型継承は所謂is-a関係の継承で特化specializeです．これは、インターフェイスの継承ともとれますし、
DDD: subclasses & root entities
Let's say I have the typical entity Car class Car : Entity { public double MaxSpeed { get; set; } public Color Color { get; set; } /* ... */ } This entity, in my domain model, would be the root entity of an Aggregate. Now let's say I specialize cars. I create a Ferrari, and the happy owners of Ferraris like to call them by a nickname: class Ferrari : Car { public string Nickname { get; set; } } Le
AdventureWorksをモデリングしてDDDしながらドメインモデルで実装してみる（１０） - 開発思考実験日記
ドメインモデルにサービスを導入する サービスというといくつかあるのですが、ここではSOAやFacadeなどのテクニカル的なものではなく、ビジネス・オブジェクト*1が提供する機能のサービスを指します。このため、ここでのサービスは画面や通信、永続化メカニズムに依存しないPlainなObjectで構成されます。 ビジネス・オブジェクトとしては典型的なものとしてはエンティティがありますので、エンティティの機能もサービスとして考えれます。実際利用されるサービスの多くはエンティティのものになります。ただ、サービスのいくつかはエンティティとは関連しなかったり、エンティティの責務範囲を超えることもあります。このような場合は新しくサービスのクラスを導入します。 たとえば「休暇申請」サービスは多くの処理は従業員エンティティで実行できそうなのですが、上司がいない場合のビジネスルールは従業員エンティティの責務をこ
Martin Fowler's Bliki in Japanese - ドメインモデル貧血症
http://martinfowler.com/bliki/AnemicDomainModel.html これはずいぶん昔からあるアンチパターンのひとつですが、今になって台頭してきているようです。 Eric Evans と話したのですが、彼も、それがだんだんポピュラーになってきていることに気づいていました。 私たちほど大の「真Domain Model」推進者としてみれば、ちょっとうれしくありません。 ドメインモデル貧血症の基本的な症状は、一見、それが本物のドメインモデルに見えるという点です。オブジェクトがいくつかあり、それらはドメイン空間にある名詞から名前をつけられています。それから、オブジェクト同士がしっかりとしたリレーションで結びついており、本物のドメインモデルと同じような構造を持っているのです。 ただし、オブジェクトの振る舞いを見れば違いが分かります。それらのオブジェクトにはわずかな
DevLOVE「DBも、進化せよ。」へ行ってきた - 虎塚
金曜の夜、DevLOVE勉強会「DBも、進化せよ。」へ行ってきました。 今回は、Jiemamyというオープンソースプロジェクトについて、開発者の都元ダイスケさんご本人が、コンセプトから特長まで丁寧に紹介してくださいました。Jiemamyというのは、開発モデルであり、DBの進化的設計を補助するツールです。…なんて書くまでもなく、おそらく有名ですよね。 当日の発表資料は、都元さんが公開してくださっています。 DevLOVE DB勉強会「DBも、進化せよ。」 - 都元ダイスケ IT-PRESS というわけで、学んだことと感想をメモしておきます。学んだことのメモは、あくまでも自分の解釈なので、誤りがあるかもしれません。 都元ダイスケさんによる発表 Jiemamyとは、Smart Build、Smart Version Control、Smart Modelの考え方に基づくDBの進化的設計を支える開
外国人が日本のテレビ番組をつまらないと思うワケ - ライブドアニュース
外国人、特に欧米人には日本のテレビ番組をつまらないと思っている人が多いようだ。これは、過去にガジェット通信の記者がヨーロッパ各地から日本に訪れたことがある外国人たちに「日本のテレビ番組の感想」を聞いてわかったことで、多くの外国人たちが「つまらない」と語っていた。その理由はこうだ。 「日本テレビ番組は芸能人のキャラクターを知らないと笑えないものばかり。番組自体がおもしろいわけじゃない。芸能人のキャラクターという予備知識があってはじめて楽しめる番組ばかりで、何がなんだかわからない」（ドイツ人男性） 確かに、日本の番組はお笑い芸人のキャラクターのおかげで成り立っているものが多い。欧米のように、「たとえ出演している芸能人を詳しく知らなくても楽しめるコメディやドキュメンタリー」などの番組は日本において数少ない。日本のゴールデンタイムにテレビを観た外国人は、「よくわからない人たちがバカ騒ぎをしている番
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ソシオメディア | UIデザインパターン