俺がポリモーフィズムだ！ - はてなかよっ！
Twitterで一瞬盛り上がった．俺の中のポリモーフィズムは簡単に言えば「一つの識別子が複数の型を持てる」というもの．オーバーロードもポリモーフィズムに入ると思っていたのだけど，「ﾜﾛｽｗｗｗｗメッセージに応答するオブジェクトが実行時に決まることなんだから入らないだろjkｗｗｗ」(誇張あり)とreplyを貰った．俺自身はプログラミング苦手なのでこの辺よく分かってないのだけど，実行時に決まるのはあくまで動的束縛などを利用したポリモーフィズムの一つでしかない，と思っているのだけどどうなんだろうか？ 「動的(実行時)なものがそうだ！」というのもあったけど，同じコードでもフローによって静的/動的が変わってしまうかもしれないし．とすると違う人から，それは擬似ポリモーフィズムですよ，静的ポリモーフィズムですよ，ともう皆さん本当プログラミングが好きですね，と． 言いたいことは何かというと，ここの説明を信
いまさらですが、職業Javaプログラマーなら理解しておいてほしい「継承」の意味について - 達人プログラマーを目指して
正しく意味を理解している方にとっては、まったく常識レベルの話であり、何をいまさらと思われる方々も多いかと思いますが、大規模案件のレガシーコードなど、私が仕事で見かけるJavaのコードを読むと、「このコードを書いたSEやPGの方々は、はたして継承の意味を正しく理解していないのではないか」と思われる設計のコードに出会うことが少なからずあります。現在では改良されましたが（Javaプログラミング能力認定試験の問題がかなり改善されていました - 達人プログラマーを目指して）、以前のJavaプログラム認定試験の問題は、そうした不適切な設計がされている典型的な例となっていたのですが、実際、SI業界ではあのような品質のコードのシステムが今でも現役で多数稼動しているというだけでなく、現在でも新たに生み出されているというのは残念ながら紛れもない事実のようなのです。 確かに新人研修で「哺乳類を継承して犬クラスと
集約とコンポジションの実装方法:アーキテクト360
.NETアプリケーションのアーキテクチャやフレームワーク、設計に役立つ情報を中心に紹介しています。また業務システムに役立ちそうなユーティリティやノウハウをサンプルコードつきで公開しています。言語はC#とVB.NETを扱っています。 UMLでクラス間の関係が集約とコンポジションである場合の実装例をC#とVBで紹介する。集約は白抜きのひし形を付けた関連で、コンポジションは黒塗りのひし形を付けた関連であり、どちらも関連の一種である。その違いを簡単に説明すると、集約が弱い結びつきであるのに対して、コンポジションは一心同体の強い結びつきを表す。集約は、関連する先のオブジェクトが最初からある場合もあるし、外したり、後から追加されたりするような関係である。一方、コンポジションはオブジェクトが生成されるときに、関連する先のオブジェクトも同時に生成され、破棄されるときは同時に破棄されるような関係である。 実
こうもり問題 - Wikipedia
こうもり問題（こうもりもんだい）とは、情報や物品を分類する際に生じる問題の一つである。例えば A にも B にも分類できる場合に、どちらに分類すればいいのか、といった問題である。 すべてのものや情報は、利用される文脈に応じて複数の属性を持ち得る。しかし、階層構造のように、各項目を木構造の末端にあてはめて分類する方式（図書館資料など）では、項目が持つ複数の属性のうちの一つだけに着目しなければならないという制約がある（たとえば「自民党税制調査会の記録は政治と税金のどちらに分類するか」など）。こうもり問題とは、その制約が原因となって生じる諸問題を指す。 身近な例では、以下のようなトラブルがこうもり問題として挙げられる。 ファイルをフォルダ分けして整理する際に、どこのフォルダに入れたらいいか迷う。 ショッピングセンターで買い物をする際に、目的の商品を探し当てるためにいろんなジャンルのコーナーを歩き
モバイルゲームの歴史を年代別にご紹介します。モバイルゲームの成長と今後について詳しく解説していきます。
モバイルゲーム 物凄い勢いで勃興したモバイルゲーム業界は、いろいろな課題や問題に直面しながらも巨大化し、今日の時点でのスマートフォン向けゲームの市場へと継承されていきます。 モバイルゲームの歴史 2001 Javaアプリと3Dゲームの登場 Javaが利用できるようになったことにより、ダウンロード型のゲームが供給できるようになりました。 2002 携帯電話端末の大容量化・3D化競争 Java搭載携帯電話端末が登場してからごく僅か1年の間に、アプリのサイズに関しては10倍に広大化し、表現方法も2Dから3Dにシフトし始めました。J-PHONEは『ゼビウス』や『スペースハリアー』などといった昔のアーケードゲームを、ドコモはSIMCITYなどパソコンで世界的規模のヒットを飛ばしたゲームを主力商品としていました。 2003 モバイルゲームの一般化 メモリの制限が厳しいJava仮想マシン上ではなく、OS
『インターフェイス指向設計』読了
最初にオススメポイントだけ書いておく。この本には テスト容易性の確保複雑性保存の法則への対処へのヒントが詰まっている。 kakutani.com にアサマシセンターがあるのかと思ったけどなかったので自分ので貼っちゃうよ。献本なのに自分のアサマシ貼ってるなんてふてぇやつだよ、オレ。 読み手に推奨される準備まずはじめに「本書の読者対象」を挙げておくと、 本書は、ある程度のプログラミング経験と、オブジェクト指向設計の基本的な知識を持つ開発者を対象にしています。オブジェクト指向に深い造詣がある読者でも、インターフェイス指向のアプローチを学ぶことで、これまでにはなかった設計の概念を得ることができるようになるでしょう。また、インターフェイスを理解することは、SOA（サービス指向アーキテクチャ）の設計においても有用です。 と書かれている。 正直に告白すると自分はこれをなめていた。普通に UML もデザイ
究極のインターフェース指向設計
オブジェクト指向言語では、メソッドを定義しただけで中身を実装しない、インターフェースが登場します。 インターフェースを使うと、クラスやメソッドの再利用性が高まります。インターフェースさえ同じなら、同じコードを、いろいろなクラスに適用できるためです。 しかし、インターフェースを使うのは、コードを再利用するためだけではありません。たとえ再利用しなくても、敢えてインターフェースを作ることもあります。むしろ、再利用するか否かに関わらず、インターフェースを使うべきだ、という考えもあります。 ここでは本屋さんのシステムを例に、インターフェースの存在意義について考えてみます。 本屋さんのクラス設計 本屋さんですから、まずは「本」クラスが必要です。「本」クラスは、下記のようないろいろな属性を持ちます。 題名 著者 発行者 値段 重さ ページ数 次に、本を購入するための「会計システム」を作りましょう。 レジ
疎結合がソフトウェア開発を変える（1）
図1●オブジェクト指向の問題点を解決する オブジェクト指向技術が浸透するにつれ，その問題点が明らかになってきた。これを解決するキーワードが「疎」である。 図2●部品化のメリット システムを分割してうまく部品化できれば，さまざまなメリットが生まれる。中でも重要なものは，同じ部品を他のシステムで再利用できること，変更を加えたときに影響が及ぶ範囲を部品内に限定できること，部品を別のものに入れ替えることでシステムの変更や拡張が容易になること，である。 オブジェクト指向言語の考え方が登場してから30年余。オブジェクト指向は，ソフトウェア開発の現場にようやく定着してきた＊1。システム・インテグレーションの現場では「案件のほぼすべてが，オブジェクト指向開発」（日本ユニシス・ソリューション AD CoE コンピテンスセンタ統括部長の川口真一氏）。「システムを発注する側が，設計情報をUML（Unified
StateパターンとStrategyパターンは何が違うのか考える | Tricorn Tech Labs
最近、物欲に目覚めてしまってAmazonでいろいろ買ってたら、今月の請求が7万を超えて素に戻ってしまった戸田です。 ちょっとbluetoothデバイスに凝り始めてしまって…。（汗） さて、オブジェクト指向設計のバイブルと言えば、いわずと知れたGoF本（オブジェクト指向における再利用のためのデザインパターン、Erich Gamma, Ralph Johnson, Richard Helm, John Vlissides著、ソフトバンククリエイティブ刊）です。 ここで紹介されている23のパターンはどれも小手先のテクニックではなく、エッセンスが抽出されており応用範囲が広いものばかりです。 なによりも今まで暗黙知になりがちな、設計の定石・パターンに共通の名称（言語）を与えて、名称による概念の共有ができるようになったという功績は計り知れません。 もちろん、KREISELにおいてもこれらのパターンを活
perlmod - Perl のモジュール (パッケージとシンボルテーブル) - perldoc.jp
Perl provides a mechanism for alternative namespaces to protect packages from stomping on each other's variables. In fact, there's really no such thing as a global variable in Perl. The package statement declares the compilation unit as being in the given namespace. The scope of the package declaration is from the declaration itself through the end of the enclosing block, eval, or file, whichever
perl - Inside-out Object : 404 Blog Not Found
2007年03月11日03:30 カテゴリLightweight Languages perl - Inside-out Object ところが、そのないはずの隠蔽化を強制する仕組みがすでに発見されているのです。 Perl Best Practices Damian Conway [邦訳:Perlベストプラクティス] ビンゴ中西のほげほげ Kansai.pm第8回ミーティングに行ってきました@荷造り中そして、Perlのオブジェクト指向には 隠蔽化を強制する仕組みはない いつか書こうと思っていたけど、ちょうどいい機会なので。 ここでは例として、name,uriという二つのインスタンス変数を持つオブジェクトを実装してみます。 InsideOut.pm { package InsideOut; use strict; use warnings; my %objects; sub new { my
継承の仕組み - Perl入門ゼミ
Perl › オブジェクト指向 › 継承の仕組み Perlにおける継承の仕組みを解説します。 1. 継承の仕組み 継承の仕組みは上位クラスに対してメソッドの探索をしているということです。前回のコードをもう一度見てみましょう。 use strict; use warnings; # コンポーネントクラス package Component; sub x { return 5 } # ボタンクラス package Button; # 継承の記述 our @ISA = ('Component'); sub new { bless {}, 'Button' } package main; # ボタンクラスを使用する my $button = Button->new; print $button->x; Buttonクラスには、x というメソッドがないのに、 x というメソッドを呼び出しているのでし
Perlのinstanceof演算子のベストプラクティスは何か - Unknown::Programming
instanceof演算子 - Islands in the byte stream 確かに遅いですよねぇ。 ただ、一応ベンチとってみたところ、blessed使うのが一番早かったです。 以下、$xがオブジェクトの場合のベンチ。 use Benchmark qw(cmpthese timethese :hireswallclock); my $x = bless {} , 'Foo'; my $class = 'Foo'; cmpthese(100000,{ ref_eval => sub { if ( ref($x) && eval { $x->isa($class) } ) {} }, scalar_util => sub { if ( Scalar::Util::blessed($x) && $x->isa($class) ) {} }, param_util => sub { if
オブジェクト指向プログラム言語としてのJavaScript
このページでは、JavaScriptのオブジェクト指向言語としての側面を研究します。 JavaScriptは、HTMLの拡張という側面が注目されていますが、 プログラム言語として見た場合にも、興味深い独自の特徴がたくさんあります。 このページでは、これらJavaScriptの言語としての特性、 特にオブジェクト指向言語としてJavaScript を見た場合の特徴について詳しく研究を試みます。 JavaScriptは、ほぼ完全なオブジェクト指向言語です。プログラマによるクラス定義、プロパティ定義、メソッド定義ができます。継承は、言語の基本機能としては用意されていませんが、基本機能の組み合わせにより実現できます。 メソッドのバインディング(binding)はレイトバインディング（late binding）です。これは、JavaScriptが変数の型のない言語だからです。 JavaScriptに
4. FactoryMethod パターン
2012/04/26 一部修正しました デザインパターン 4章 FactoryMethod パターン 4.1 FactoryMethodパターンとは 4.2 サンプルケース 4.3 FactoryMethod パターンのまとめ 4.1 FactoryMethodパターンとは 第4章では、FactoryMethod パターンを紹介します。FactoryMethod パターンは、オブジェクトの生成方法に一工夫加えることで、より柔軟にオブジェクトを生成することを目的とするものです。FactoryMethod パターンでは、インスタンスの生成をサブクラスに行わせることで、より柔軟に生成するインスタンスを選択することが可能となります。 オブジェクトを生成する場合、下記のように記述するのが普通です。 Product product = new Product(); しかし、このようなオブジェクト生成方
DIって本当に必要? - ひがやすを技術ブログ
DIって本当に必要?たまにそう思うときがあります。DIによって開発は本当に楽になったのか。 DIのメリットでよく語られることとして、インターフェースと実装を分離し、機能の利用者側はインターフェースを通じて機能を利用することで、実装に直接依存しなくなり、後で実装を変更しても影響を受けなくなるということがあります。 実際後から、実装クラスを変更するということはめったにないので、よくあるのは、テストのために実装クラスをモックに変えることです。 でも、別にそれだけならDIContainerなんていりません。たとえば、次のようにServiceクラスに直接依存したClientがあるとします。 class Client { Service service = new Service(); void setService(Service service) { this.service = service;
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Martin Fowler's Bliki in Japanese - FrontPage
Amazon.co.jp: 実装パターン: ケント・ベック (著), Kent Beck (著), 永田渉 (監修), 長瀬嘉秀 (監修), 永田渉 (読み手), 長瀬嘉秀 (読み手), 株式会社テクノロジックアート (翻訳): 本
【GOF】デザインパターン
Map does not extend Iterable. Why ? (Beginning Java forum at Coderanch)