発達したオブジェクト指向は見えなくなる - 青鬼としてのオブジェクト指向 - uehaj's blog
「業務アプリの業務部分で、オブジェクト指向なんか使わないよね」（Re)という話が出てますのでちょっと思うところを書いてみます。 オブジェクト指向の究極は、オブジェクト指向であることがみえなくなるのだと思う。 フレームワークって言うのがまさにそうで、フレームワーク自身が設計の多くをまかなう故に、オブジェクト指向設計をさせない作りになる。テンプレートメソッドのメソッドを埋めればアプリとして動作する。例えばGrailsを使う場合、アプリをくむ立場からはオブジェクト指向の要素はほとんどありません。でも使ってない訳じゃなくて、間接的に使っていて、使っていることが見えないほど巧妙になっているだけ*1。 クラスライブラリというのもそういうものです。継承を多用させるなど、オブジェクト指向を熟知することを利用者に強要するようなクラスライブラリは、API設計としてはよろしくない。 しかし、それは、オブジェクト
カプセル化、情報隠蔽、データ隠蔽 - ぐるぐる～
あちこちのサイトを見てると、間違った解釈をしてるのが多い。カプセル化なんて、情報隠蔽まで含んでるのが常識になりつつあるような。。。ここまで一般化してると情報隠蔽してるのがカプセル化というのが常識なのかも。 カプセル化・情報隠蔽・データ抽象化 - 今日の役に立たない一言 − Today’s Trifle! − カプセル化と情報隠蔽、データ隠蔽の違いがよくわからくなったので、手持ちの本で調べてみた。 基準 基準としては、 カプセル化、情報隠蔽、データ隠蔽の関係 カプセル化は隠蔽を含んでいるかどうか 対象はクラスのみか、そうでないか などなど。 一番目はそのまんま。二番目は、 // 隠蔽せずともカプセル化か class Hoge { int hoge; // なんかhogeを使うメソッド } // 隠蔽しなければカプセル化ではないか class Piyo { private int piyo;
polymorphism とか inheritance とか - odz buffer
ref:「難しい言語」の補足 - カレーなる辛口Javaな転職日記 ref:ポリモーフィズムは継承の面白い副作用..なんかじゃない - みねこあ ref: 継承という手段 - みねこあ wtnabeさんも書いていたことなんだけど、結構な人が「オブジェクト指向 = Java のオブジェクト指向」だと思っているようです。それはなんだかちょっと悲しいなぁ。 ということで適当にまとめることに挑戦。 まず、大前提として静的型付け言語ではメソッドシグネチャ*1 を宣言しておかないとメソッドの呼び出しができない*2。このメソッドシグネチャの集まりを型とかクラスとか呼んだりするするわけですな。 で、Java では継承と型階層を導入することで、異なるクラスのインスタンスをまとめてひとつの型で扱えるようにして、ポリモーフィズムを実現しているのである。要するに class Base { } class Deri
クラスと型 - みねこあ
クラスから型の側面をズバッと切り離すと、 オブジェクトのファクトリ オブジェクトの処理の移譲先 と言う風になると思います。（特定言語圏の話かもしれないけれど） * * * クラスベースな OOPL の場合、オブジェクトは自身にメッセージが送られども、実際自分でそれに対する処理を出来るわけでは無くって、クラスに処理を委譲してやってもらいます。クラスベース オンリーなOOPLの場合オブジェクトが自前でメソッドを持つのは禁則事項です♪ になるわけです。こういう意味ではオブジェクトファクトリ(生みの親)であるクラスを「母」と喩えれば子はみんな臑齧り。「おかーさん、コレやって」「おかーさん、あれやってー」・・・なんだか凄く不健全な気がしてきたョ orz... プロトタイプべースな OOPL の場合、オブジェクトは処理を委譲しないで自力で解決可能になります。値と同じようにメソッドもオブジェクトが持つこ
メッセージ指向なオブジェクト指向でのUMLって？
オブジェクト指向は単なるオブジェクト間のメッセージのやり取りに過ぎない、という言葉は、僕の身近な人たちにとっては僕から一度は聞いたことがあるだろう。そんな考えに関して注目エントリが下記。書いてある内容はほぼ同意なんだけど、部分的に引っかかりを感じざるを得ないので、僕の意見をエントリしてみる。 「 イマドキのオブジェクト指向」- アークランプ より： では、「イマドキのオブジェクト指向」とは何か。それはメッセージ指向という解釈です。オブジェクト指向は「メッセージによる処理の分割」であり、「分離された処理をオブジェクトと呼ぶ」と定義します。これまではオブジェクト指向とは「オブジェクトによる処理の分離」であったわけです。 太古の昔から、オブジェクトは「メッセージのやり取りによる処理の委譲の繰り返し」だったはず。「継承ではなく委譲を使いましょう」なんて思想は、オブジェクト指向の基本であり、それはメ
OOエンジニアの輪！ ～ 第６回 平鍋健児さんの巻 ～ | オブジェクトの広場
今回のゲストは、株式会社永和システムマネジメントの平鍋健児さんです。 平鍋さんは XP(eXtreme Programming) の ホームページと XP-jp(extremeprogramming-jp@esm.co.jp)というメーリングリストを運営されています。前回の長瀬さんに続き、 XP の話題で盛り上がりました。 株式会社永和システムマネジメントのご紹介 --- 最初に、永和システムさんについてご紹介願えますか？ 福井にある150名くらいの独立系ソフトハウスです。主な業務は金融、医療、オープン系の3つですね。私は「情報テクノロジ」というオープン系のセクションで、20名くらいでオブジェクト指向してます。 --- Jude の開発もされてますよね。 ええ。Judeはいろんな方に興味を持って頂き、嬉しく思っています。でもJavaで書いたのは失敗でしたね。 なんていうか、デスクトップで使
Perlオブジェクト指向プログラミング
-> 趣旨と注意書き -> 身近なpackage -> なんのためのpackage ? -> What's `new' ? -> bless ( reference => package ) -> Hello, Module World! -> オブジェクト？ -> main パッケージと関連付けてみる -> クラスとメソッド -> オブジェクト指向 -> オブジェクトがリファレンスなら… -> -> を連続する -> 継承 -> 多重継承 -> 多重継承をやめる -> 多重継承をやめる(もう少し簡単に) -> 情報源(書籍等) <- モドル 趣旨と注意書き これを読んでも、あんまりきちっとした知識は、身に付きません（^^; オブジェクト指向の概念はほんの少ししか説明しません。ここで述べるのは、Perlでどうやるかってのが主です（それも不十分＆嘘まじりかも）。 とりあえず、モジュールを作り
いまさらながらだけど、オブジェクトとクラスの関係を究めてみようよ - 檜山正幸のキマイラ飼育記 (はてなBlog)
オブジェクトとクラスの関係について、次のような説明を見かけました（文言の引用ではなくて、檜山による要約）。 オブジェクトとクラスは全体としてツリー構造をしていて、ツリーの末端をオブジェクト、末端以外のノードをクラスという。末端であるオブジェクトは、その親ノードであるクラスのインスタンスと呼び、クラスどおしの親子関係を継承関係と呼ぶ。 うーむ、この説明、ある意味「簡潔でわかりやすい」とも言えるのだけど、ちょっと単純化し過ぎでしょ。 オブジェクトやクラスの概念て、そんなに美しくもなきゃ、整合的でもありません。実用性やら実装上の都合やらでゴチャゴチャですがね。しかし、そのゴチャゴチャが悪いともいえません。ゴチャゴチャを無理に単純化することなく、必然性を持った（幾分は偶発的だけど(苦笑)）複雑さとして理解すべきかと思います。 というわけで、メタクラスやレイフィケーション（reification）な
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
サービス終了のお知らせ
http://blueperiod.blog.shinobi.jp/Entry/832/