トレイトのフラッティング - みねこあ
Traits は、inline関数や Cのマクロに似ています。 Traits を クラスに use した際に、継承や委譲と違い、メソッドの持ち主を指し示すのではなく、メソッドそのものをクラスに展開してしまいます。これは通常のコール/リターンする関数と、 inline関数や Cのマクロ の間柄によく似ています。 これを「フラッティング」と呼ぶのですが、たいていは実効効率 の問題で用いられる inline関数と違い、Traits の場合「フラッティング」は可読性の為だと言います。 Even though a class may have been constructed by composing small traits in a complex hierarchy, there is no need to require that it be viewed in the same way.
Open-Closed Principle とデザインパターン
1999/09/03 更新 石井 勝 さて，このセクションではデザインパターンを統一的に理解するために，「 Open-Closed Principle (OCP) 」 という設計ルールに基づいてパターンを眺めてみることにします．まず OCP の意味と解説を行い，その後デザインパターンを OCP の観点から見てみます．実は，デザインパターンのうちの多くは OCP を満たすために用意されたものと考えることができるのです．このセクションでは， OCP を理解し，数あるデザインパターンの中からどういう場合にどのパターンを使うのが一番効果的なのかを考えます． GoF のデザインパターンは，全部で 23 個ものパターンがあります．このデザインパターンは，多くの局面で繰り返し現れる設計を抽出したものですから，オブジェクト指向のエッセンスを集めたものだと言えるでしょう．オブジェクト指向には，カプセル化
自己流オブジェクト指向＆Java参考書 『非』お勧め版 - カレーなる辛口Javaな加齢日記
お奨め本リスト*1と対をなす，非お勧め版の入門書・参考書リスト．*2 あくまで『非』お勧めの、駄本、屑本リストである点に注意。しかし皮肉な話だが，初心者を惑わす入門書を避けるためにも要チェックだろう． 主に「何故か有名だけど悪い本」を取り上げる予定．「無名だけど悪い本」はきりがないので，ここではパス．結果として持ってない本が中心になるので詳細について触れるつもりはない．*3 「オブジェクト指向本」 実は「オブジェクト指向」というのは，あまり専門的な用語ではない．*4オブジェクト指向プログラミング(OOP)，オブジェクト指向設計(OOD)，オブジェクト指向分析(OOA)などと，きちんと区別すべきだ．ただ口頭で話す時は「オブジェクト指向プログラミング」と言うのは冗長だしOOPと言っても理解してもらえない．しかたがないので省略して「オブジェクト指向」と言う時も少なくない． ここで挙げるのは「いわ
多重継承を禁止したらJava以下じゃないか！ - 神様なんて信じない僕らのために
C++を使っていると、たまに「よくわからないから多重継承は禁止」とかいう規約があることがある。 ……馬鹿じゃないかしら。 とまでは言わないわけだけれども、 C++から多重継承を取り上げたら、Javaの継承よりも弱くなっちゃうじゃないか！ くらいは言いたい。 そう、多くの場合多重継承禁止という事は即ち「インターフェイスも禁止」ってことだ。 Ω ΩΩ＜な、なんだってー！ Javaでインターフェイス禁止とか言われたら正気の沙汰ではないと思われるに違いないが、 C++ではそういう事があり得るから困る。 要するに多重継承とは危険なものだ、 というどこからか聞きつけてきた知識がそうさせるのか、 本人がよく理解してないからかはわからないが、 別にいいじゃんねえ。 継承関係は見ればわかるし、 メモリの配置くらいイメージすればいいじゃん。 元々ルートオブジェクトが存在しないC++において 多重継承を奪われる
なんで多重継承はそんなに嫌われるのか？ ちょっくら分析してみるか - 檜山正幸のキマイラ飼育記 (はてなBlog)
多重継承を嫌う人は多いですよね。「複雑だからダメだ」ってことらしい。でも、「複雑＝ダメ」はちょっと乱暴。必然性／必要性がある複雑さなら、それは受け入れざるをえないのですから。それに、どの程度の複雑さなのか、その複雑さはどこから来るのかを知らないと「ダメ」かどうかの判断はできないと思います。 という次第で、多重継承の複雑さを調べてみます。ダメかどうかの判断は僕はしません。圏論の道具を使うのだけど、事前の知識は一切不要です（最後の節を除いて）。最後にまとめて圏論的な解釈をしますが、ここは省略可能。 内容： クラスとその例 多重継承は集約と単純継承の組み合わせ 嫌われる理由 1：名前のバッティング 嫌われる理由 2：ダイアモンド継承 ダイアモンド継承の対処 とりあえずのまとめ 圏論からのアプローチと整理 クラスとその例 多重継承の話をするので、もちろんクラス概念は仮定します。でも、複雑さの話を複
いまさらながらだけど、オブジェクトとクラスの関係を究めてみようよ - 檜山正幸のキマイラ飼育記 (はてなBlog)
オブジェクトとクラスの関係について、次のような説明を見かけました（文言の引用ではなくて、檜山による要約）。 オブジェクトとクラスは全体としてツリー構造をしていて、ツリーの末端をオブジェクト、末端以外のノードをクラスという。末端であるオブジェクトは、その親ノードであるクラスのインスタンスと呼び、クラスどおしの親子関係を継承関係と呼ぶ。 うーむ、この説明、ある意味「簡潔でわかりやすい」とも言えるのだけど、ちょっと単純化し過ぎでしょ。 オブジェクトやクラスの概念て、そんなに美しくもなきゃ、整合的でもありません。実用性やら実装上の都合やらでゴチャゴチャですがね。しかし、そのゴチャゴチャが悪いともいえません。ゴチャゴチャを無理に単純化することなく、必然性を持った（幾分は偶発的だけど(苦笑)）複雑さとして理解すべきかと思います。 というわけで、メタクラスやレイフィケーション（reification）な
Singletonを実現するgetInstanceが推奨できない理由 - 神様なんて信じない僕らのために
id:nicht-seinさんからコメントがあったので書いてみます。 まず、コメントにも書いてくださったようによく見かけるこれ （僅かに手を加えました） class CHoge { private: CHoge() : value_(100) {}; ~CHoge(){}; int value_; public: void setHoge(int value) { value_ = value; } int getHoge() const { return value_; } static CHoge& getInstance() { static CHoge instance_; return instance_; } }; 他からnewされないようにコンストラクタがprivateになってます。 勿論、スタックに置くためにCHoge hoge;もできません。 でも、実はこれはインスタンス
プリミティブ値でもプロトタイプ的継承: Days on the Moon
書き上げた後に元記事の続きが出ているのに気づいたが、方向性が違うようなのでそのまま掲載。 404 Blog Not Found:javascript - プロトタイプ的継承 (元記事: Prototypal Inheritance) より。継承という言葉は意味が広いので、この操作に対してはチャイルドの作成といったほうが個人的にはわかりやすい。 さて、元記事で紹介されているコードではプリミティブ値からのチャイルドの作成 (継承) ができなかった。これはなぜかといえば、オブジェクト作成の際、プリミティブ値をプロトタイプ ([[Prototype]] 内部プロパティ、__proto__ プロパティ) に設定することはできないからである。 そこで、プリミティブ値が渡された場合は、それをラッパオブジェクトに変換することにする。といっても場合分けの必要はない。Object 関数を使えば、プリミティブ値
継承という手段 - みねこあ
ポリモーフィズムは継承の面白い副作用..なんかじゃない - みねこあ のコメント欄より。田辺さんとのやり取りで、私が相当おかしなことを言っている件について。 「インターフェイス継承」という言葉が、仕様を引き継ぐことなのか、Java の Interface のような 実装をまったく含まないクラスからの継承を指すのかが曖昧に感じられるため、前のエントリではお茶を濁していたのですが、これは本質ではなく、さらなる混沌とモヤモヤ時空を作り出してしまっています。また脳内知識だけで書いてしまったための「嘘」も見受けられます。その結果、新たな オレオレOOP を作り出さんとばかりな、感じになっていて、これは非常によくないです。だめだめだ、あたし。 なので、ちゃんと「インターフェイス継承」と「実装継承」で説明しようと思いました。まず「インターフェイス継承」の、誤解を呼ばない別のいい表現がないかな、と捜してみ
レコードの型階層を合理的に説明できるか その3 - 檜山正幸のキマイラ飼育記 (はてなBlog)
前回（その2）から引用： “未定義の定義”ごとに、型や型階層の概念が少しずつ違ってきます。それらは並列に存在する異なった定式化であり、優劣を論じても生産的ではありません。無理に優劣を付けようとすると、不毛な議論になるわけです。 というわけで、「未定義とは何か」を中心に話を進めます。 ton1 = {name: "板東トン吉", age: 27} のとき、ton1.marriedは“未定義”です。この状況の取り扱い方として、次のような処方が考えられます。 ton1.married という式は構文エラーとして前もって排除する。 ton1.married はどんな値にもなり得ると考える。 ton1.married はどんな値でもないと考える。 ton1.married はある特別な値であると考える。 1番目の考え方は話題にしません。残りの3つを扱います。4番目は現状のJavaScriptの方法と
自己流オブジェクト指向プログラミング＆Javaお奨め本2007年版 - カレーなる辛口Javaな転職日記
http://d.hatena.ne.jp/JavaBlack/20050909/p1の改訂．*1基本的に改訂版への差し替えと一部の新刊の追加程度になっている． お奨めのJava＆オブジェクト指向プログラミング関連の書籍／参考文献リスト．初心者向け入門書や参考書から上級者向けの専門書まで，オブジェクト指向だとかJava言語とかの初心者〜中級者が学習をすすめる上での参考にすることを想定して作っている． 初心者向け勉強の手引き：http://d.hatena.ne.jp/JavaBlack/20070825/p1 オブジェクト指向プログラミング とりあえず初心者なら「オブジェクト指向プログラミング入門」「オブジェクト指向における再利用のためのデザインパターン」と，あと「リファクタリング―プログラムの体質改善テクニック (Object Technology Series)」くらいかな．ただしリフ
オブジェクト指向の法則集
1999/07/07 更新 石井 勝 はじめに ここでは，オブジェクト指向に出てくる法則・原則をまとめました．パターンに比べてほとんど知られていないのが現状ですが，優れたオブジェクト指向開発者を目指すならデザインパターンよりまずこっちを理解し覚えてしまいましょう． これらの法則は，絶対守らなければならないというものではありません．開発中に法則が守られているか意識することが重要です．つまり 今行っている設計はその法則が守られているだろうか その法則を破っている場合，破るべき正当な理由があるだろうか と絶えず考えるようにしましょう．そうするとそれは自然に優れたオブジェクト指向設計になるのです．つまりこれらの法則は，優れたオブジェクト指向開発のための指針なのです． Robert C. Martin の Principles of OOD Robert C. Martinは，オブジ
オブジェクト指向を正しく理解する - 特集 オブジェクト指向は難しくない！：selfup
オブジェクト指向はしばしば，とっつきづらく難しい技術と言われます。その理由の一つには，対象とする分野が広く，それぞれに深みがあることが挙げられます。しかし，それ以上にこの技術を難しくしている落とし穴とも言うべき原因が二つあると筆者は考えています。それは比喩を乱用する説明の仕方の問題と，「もの中心」を意味するコンセプト自体の問題です。 そこで本特集では，「オブジェクト指向という言葉をよく聞くけど，実際どんなものかよくわからない」という方のために，初心者/入門者が陥りやすい落とし穴を明確にしながら，オブジェクト指向の全体像を説明します。余計な先入観やまぎらわしいたとえ話に惑わされなければ，オブジェクト指向そのものはそれほど難しい技術ではないことを理解していただきたいと思います。なお，オブジェクト指向プログラミング，デザインパターン，分析/設計といった個々の技術については特集2以降でそれぞれ解説
知られざるJavaScriptの世界：ITpro
最近，Webプログラミングの世界で静かなブームになっている言語があります。何を隠そうJavaScriptです。JavaScriptはご存知のとおり，クライアントサイドすなわちWebブラウザ上で動作するタイプのプログラミング言語です。最初にJavaScriptが実装されたのは，今から10年以上前の1995年，Netscape Navigator2.0でのことです（登場当時はLiveScriptと呼ばれていました）。決して新しい言語ではありません。それが，どうして再び注目されることになったのでしょう。その理由は，Webインタフェースのプログラミングで，JavaScriptの有効性や利便性が再発見され，言語そのものが持つユニークさや機能が技術者の関心を集めているからです（図1）。 JavaScriptを使うのはダサかった？ Webインタフェースの技術といってもHTMLしかなかったころ，様々なプロ
【オブジェクト倶楽部： 2004-07 号】
Date: Wed, 25 Feb 2004 12:30:01 +0900 Subject: 【オブジェクト倶楽部： 2004-07 号】 ┏━━━━━━━━━━━━━━━━━━━━━━━━━━■ ┃ ■┃ ●┃● ● オ ブ ジ ェ ク ト 倶 楽 部 ■ ┃ ┃ ■ ┃ ┗━━━━━━━━━━━━━━━━━━━━━━■━━━┛ No.35 2004/02/25 ■ I N D E X ┃ ┣【Topics】デザインパターンワークブック発売のお知らせ ┣【プログラミング】コード＝カタで目指せ達人プログラマ [0] ┗【アンケート】気になるシステム業界 ホントのところ 〇━━━━━━━━━━━━━━━━━━━━━━━━━━━T o p i c s━ 〇 デザインパターンワークブック発売のお知
Kazuho@Cybozu Labs: JavaScript は、なぜプロトタイプベースなのか
« JavaScript を学ぶ上で読むべきウェブサイト | メイン | re: javascript vs perl - オブジェクトのメモリー効率 » 2006年10月19日 JavaScript は、なぜプロトタイプベースなのか 決して専門ではないので、以下、間違っていたら指摘してください。 JavaScript がプロトタイプベースであることに対する一番妥当な説明は、クラスベースのオブジェクト指向言語よりもプロトタイプベースの言語のほうが、ランタイムの構造が単純になり、かつ、メモリ使用量が小さくなるからでしょう。 クラスベース OO のランタイムを作成しようと思うと、以下の各機能が必要になります。 1) クラス毎: メンバ関数を納めるハッシュテーブルと、親クラスを指すポインタ 2) インスタンス毎: プロパティを格納するハッシュテーブルと、クラスへのポインタ また、インスタンスの生
2005-01-06
去年の12月27日の日記に著者さんからコメントをいただいたので話を蒸し返す。 確かにもう少しロールを意識したクラス名にしたほうがよかったですね。 ただ、FrameState(とそのサブクラスたち)は計算以外にも次の状態への判定などもおこなっているので、計算するクラスと別のクラスに。。。 クラスの命名ってやっぱり難しい。State Pattern を使う場合に、クラス名を HogeState にするならば、クラスの責務は状態遷移に関する部分が主であるべきだと思う。でも、JavaWORLD 2月号の記事にあるクラス図や本文からは、計算が主のように読めるので違和感がある(そう読めるのは主観でしかないんだけど)。 記事のモデルを見て心配になるのは、最終フレームの計算方法の違いをどうやって吸収するのか、かな。最終フレーム用の LastFrameState を作って、New と Processing
クラス、オブジェクト、型； なんだか変じゃない？ - 檜山正幸のキマイラ飼育記 (はてなBlog)
「オブジェクト指向と得体の知れないモノたち」の続きみたいなハナシ。クラスやオブジェクトをなるべく“ドライに考える”ための練習。クイズだと思っても、実務的ヒントとして受け取っても、どっちでもいいですよ。 この継承は変な感じ class Point2D { protected double x; protected double y; // コンストラクタ（略） void moveTo(double x, double y) { // ... } // ... 点を操作するいろいろなメソッド } class ColoredPoint2D extends Point2D { protected Color color; // コンストラクタ（略） Color getColor() { return color; } // ... } class Point3D extends Point2D {
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Effective JavaScript - Dynamic Scripting
エンタープライズ アプリケーションアーキテクチャパターンObject oriented selection
