最近もらった本: インターフェイス指向設計 - steps to phantasien t(2008-07-21)
最近でもないですが頂きました. ありがとうございます > 関係者の方. 多忙にかまけて感想を書くのが遅れてしまいました. 遅れた理由はもう一つあって, 私はこの本の主張があまりピンとこなかった. でも貰った本のことを単にイマイチだったと書くのも社会人としてどうかなー, などとよたよたするうちに月日は流れ... 嘘や間違いはない. けれどアジャイルなオブジェクト指向設計という視点でみると, いまいち relevance を欠く気がする. この本を読んでまずい設計が良くなるのを期待できない自分がいる. 何でピンとこないのか, しばらく考えていた. どうも "インターフェイス" を中心に据えるのがまずいんじゃなかろうか. オブジェクト指向の設計を議論する上で, インターフェイスはツールの一つに過ぎない. "インターフェイス指向設計" という切り口は, 極端に言えば "クッキー指向ウェブアプリケー
プロトタイプベース・オブジェクト指向
prototype-based object oriented 。 オブジェクトがスロット（クラスのインスタンスならインスタンス変数やメソッドに相当）の追加をクラスに依存せずに自由にできることを前提としたオブジェクト指向。あるいはそうしたオブジェクトを用いたプログラミングや、それをサポートする機構。 「インスタンスベース」、「オブジェクトベース」とも。 これらへの言い換えは「プロトタイプベース」という言葉が持つ限定的なニュアンスを払拭するのにおおいに役立つ。しかし同時に、前者の「インスタンスベース」において特に、“プロトタイプベースにはクラスがない”あるいは“プロトタイプベースはクラスベースの対極にある（あるいはアンチテーゼである）”といったような教科書的記述に惑わされている人をひどく混乱させるらしく、極端な拒絶反応を示す人もいるので注意。また、後者においては、オブジェクトオリエンテッド＝
Perl 5 を OOP 言語にするには - Tociyuki::Diary
「sumim’s smalltalking-tos - オブジェクト指向言語として必須な要素とは何か?」のコメント欄に質問を書いていたとき、私が sumim さんの立場になったとして、もしこの質問をされたらどう答えてみようかと考えてみました。 # tociyuki 『PerlをOOPとみなすには > 関数のコールを「メッセージング」だと“読み替え”る 必要があるという部分の意味が読み取れませんでした。 Perlでは「レシーバ->メソッド名」をevalする実行時に、レシーバのクラス(レシーバが文字列スカラーならそれと同じ名称のパッケージ、もしくはレシーバーがリファレンスならばそれにblessされたパッケージ名)の継承樹を、メソッド名と同じ名称の関数を探し出してから呼び出す仕組みになっています。 この、「実行時に、その都度、継承樹を辿って関数を探し出してコール」する動作を「関数のコール」と読ん
オブジェクト指向言語として必須な要素とは何か? - Smalltalkのtは小文字です
ときどきの雑記帖 リターンズ -おしえて(OOPLの)えらいひと より。お呼びでない…とは思いましたが、私のこれまで調べたことを頭の中で整理するのに役立ちそうなので、できるだけ簡潔にまとめてみます。 ケイのオブジェクト指向（メッセージングのオブジェクト指向）に立脚する場合 このオブジェクト指向のコンセプト パーソナルコンピューティングに係わるものをメッセージングで表現。 それをサポートする言語に必須のもの メッセージング（あるいは、それに準ずる）機構と、メッセージのレシーバ（たいていは、オブジェクト。状態や処理の保持・保護・隠蔽を行なえることが期待される）。 原則として欠いてはいけない機能 可能な限りの動的性。 ストラウストラップのオブジェクト指向（ユーザー定義型のオブジェクト指向）に立脚する場合 このオブジェクト指向のコンセプト 抽象データ型（この文脈ではユーザー定義型を指す）を「クラス
関数、オブジェクト、クロージャ - FAX
(thanks to id:koyachi、del.icio.us/rtk2106) OOPとFPと。関数、オブジェクト、クロージャの使い分けについて考えます。 関数型が良いのか、オブジェクト指向が良いのか、知りたいと思っていました。色々なページを読み、現時点で一応の答えを得ました。 カウンタを例にして、関数、スコープ、オブジェクト、クロージャの順に見て行きます。関数関数は処理です。入力と出力があります。関数型プログラミングでは、関数同士の入力と出力を連結しプログラムが構成されます。 var current = 0; function next(v){ return v + 1 } function previous(v){ return v - 1 } ok( 1 == ( current = next(current) ) ); ok( 2 == ( current = next(cu
C と C++ での例外処理、第 1 部
Microsoft Learn. Spark possibility. Build skills that open doors. See all you can do with documentation, hands-on training, and certifications to help you get the most from Microsoft products. Learn by doing Gain the skills you can apply to everyday situations through hands-on training personalized to your needs, at your own pace or with our global network of learning partners. Take training Find
オブジェクト指向の概念の発明者は誰ですか？ - Smalltalkのtは小文字です
忙しい人のためのまとめ 一般に「オブジェクト指向プログラミング」と呼ばれる考え方には発案者が異なる二系統がある。（ただし簡単のため、次のうち前者から批判的に派生して生じたプロトタイプベースのオブジェクト指向はここには含めていない） アラン・ケイによる、変化に強い長期運用可能な遅延結合システムを SIMULA67 にあった「オブジェクト」をメッセージの受け手とすることで実現（オブジェクトにメッセージ送信）するアイデアに基づく「メッセージングのオブジェクト指向」と、 ビアルネ・ストラウストラップ（前後して抽象データ型を発案したリスコフ本人、オブジェクトクラスを考えたニガードらSIMULA陣営、Eiffelのメイヤーらも同様の着想を得ている）による、ユーザー定義型（抽象データ型）を SIMULA67 にあった「クラス」という言語機能を使って実現（カプセル化、継承、多態性）するアイデアに基づく「抽
「保守しやすい」ことが、良い設計(EoM = Ease of Maintenance)：An Agile Way：オルタナティブ・ブログ
前２回で、オブジェクト指向を「テスト容易性」と「変更容易性」を中心に再定義したい、という話をした。 従来オブジェクト指向の説明に使われている概念、およびそこから得られる（といわれている）再利用性という品質からではなく、 テスト容易性： EoT = Ease of Testing 変更容易性： EoC = Ease of Changing という２つの概念からが、（現代的な）オブジェクト指向設計の焦点であることを主張してきた。最後、なぜこの２つが必要なのか、というと、それは、メンテナンスのしやすさ（EoM=Ease of Maintenance）を高めるからだ。そして、このEoMこそが、2005年のソフトウェア開発の根本品質だ、と言い切ってまとめたい。 EoMの高い設計が、よいオブジェクト指向設計である。 ということである。今回は、前回書いた、EoT/EoCそして、このEoMについて、ソフト
「変更しやすい」ことが、良い設計 (EoC=Ease of Changing) - An Agile Way [ITmedia オルタナティブ・ブログ]
前回は、EoT(Ease of Testing: テスト容易性)によってよいオブジェクト指向設計を再定義したい、という表明をした。今回は、二本目のナイフを抜きたい。キーワードは、EoC(*1)(Ease of Changing)、変更容易性だ。 この記事では、 EoCの高い設計が、よいオブジェクト指向設計である。 と主張したい。設計品質の中で、「変更容易性(EoC)」を最上位と見る。 ここ10年のオブジェクト指向の最大の失敗は、「再利用性」をその最大の価値、として説明しようとしてきたこと。そして分かったことは、再利用がその努力コストに見合う効果がでることは極めて稀であること、また、テクノロジではなくソーシャルな活動が再利用に効くこと、さらに、コードの再利用ではなく、ナレッジの再利用（例えばパターン）の方が、まだ可能性があるということ（少なくとも2005年のコンテクストでは）。 再利用性では
「テストしやすい」ことが、良い設計(EoT=Ease of Testing) - An Agile Way [ITmedia オルタナティブ・ブログ]
良い設計とはなにか、と問われて、凝集度と結合度に関する議論を思いつく人も多いだろう。しかし、この定義によりもっと具体性がある設計方針として、テストを考える。テストの視点によってオブジェクト指向を再定義したい。キーワードは、Eon(Ease of Testing)、テスト容易性だ。 ぼくは、 EoT(*1)の高い設計が、よいオブジェクト指向設計である。 と主張する。設計品質の中で「テスト容易性(EoT)」を最上位と見るのだ。オブジェクト指向のさまざまな機構、用語、考え方は、すべて EoT のため、と捕らえられる。例えば、
まつもとゆきひろのプログラミング言語論（1）
リスト2 動的型の言語で書いたソースコード<BR>Rubyで記述した。ソースコードで変数の型を宣言していないが，実行時にきちんと型整合性をチェックする。数値と文字列を加算しようとすると，エラーが出る。 プログラムを実行して初めて決まる事項が多い「動的言語」。柔軟性が高い，簡潔な表現が可能など複数の利点を持っている。さらに性能の問題などの欠点がコンピューティング環境の変化で目立たなくなってきた。速く柔軟な開発が求められる中で動的言語の存在感は増すばかりである。（本誌） LAMP（Linux，Apache，MySQL，Perl/ Python/PHP）という言葉（表1[拡大表示]）が注目されています。オープンソース・ソフトウェアを利用したソリューション構築を意味する造語ですが，プログラミング言語の代表として挙げられているのはどれも動的言語です。 以前は，企業システムをPerlやPHPのようなイ
マルチパラダイムデザイン
■ はじめに James O. Coplien の"Multi-Paradigm Design for C++"の翻訳『 マルチパラダイムデザイン 』が，昨年12月にピアソン・エデュケーションから出版されました．原書は1998年10月に刊行され，その年のC/C++ユーザ協会ブックオブイヤー賞次点を取り，新しい設計手法に影響を与えてきました．ここでは，マルチパラダイムデザインが何かをご紹介して，『マルチパラダイムデザイン』を読み解くガイドライン を提供します． 今回の記事に関連して，著者がオブジェクト指向シンポジューム2000(ソフトウェア工学研究会主催，2000年8月開催)などで使用してきたプレゼンテーション資料"Multi-Paradigm Design and Implementation in C++"の 翻訳 を許可してもらいました．この資料は，(著者自身が作成しているので当然とい
traits とは
traits は 特性 と云ふ意味。何らかのオブジェクトの特性を別のテンプレートで表現するのが traits と云ふ手法。 string の例 例として馴染み深い std::string を見てみよう。string は basic_string<char, char_traits<char>, allocator<char>> の typedef として定義されてゐる。この char_traits の部分が traits である。紛らはしいが、char_traits は char 型の特性と云ふ意味ではなく、文字 (character) の特性と云ふ意味である。 ここで、文字列と云ふものについて考へてみよう。文字列と云ふのは文字の列であり、文字の型をパラメータとすることが出来る。しかし、文字の集合が異なればその詳細も異なる。例へば、比較の方法が異なるかも知れないし、効率的なコピーの方法が異
ぼくも Traits について考える。 - 言語ゲーム
なんだか Traits について考えるのが流行っているみたいなので僕も考えてみた。Traits というのは何かというと、端的には多重継承とコードの重複を同時に避ける仕組みだ。 例えば、長方形、正三角形、正方形があるとき、正方形は長方形の仲間だろうか、正三角形の仲間だろうか。 長方形の仲間だという事にすると、長方形と正方形に共通する、面積の求め方や作図の仕方をまとめる事が出来る。 正三角形と正方形をまとめると、全ての辺が同じ長さという事をまとめる事が出来る。 多重継承を使えば、正方形を両方の仲間だとみなす事も出来るがこれを避けたい沢山の理由がある(が、忘れたので書かない)。問題は物の性質を現すのに継承というのがあまりにも大雑把だという事で、Traits は、多重継承を避ける為に使う Ruby の Module のような物だ(というかメソッド名重複の解決以外は Module と一緒では?)。こ
Matzにっき(2004-01-26)
<< 2004/01/ 1 1. [生活]元旦 2. [生活] New Year's Resolution 2 1. 初夢 2. [生活]帰宅 3 1. [家族]姪を預かる 2. [家族]実家 3. [tDiary]tdiary grep 4 1. [教会]断食安息日 2. [生活]小豆雑煮 5 1. [tDiary]tdiary grep(2) 6 1. [生活]体調不良 2. [Ruby]M17N 7 1. [言語]まつもとゆきひろの「プログラミング言語論」【前編】 2. [Ruby]M17NとCitrus project 8 1. [生活]出社 2. [M17N]Citrus Project 3. [テレビ]『FIRE BOYS』 4. [tDiary]tdiarygrep(3) 5. [M17N]文字オブジェクト 6. [news]年始、ロボットと愛し合う 9 1. [言語]Pla
DI コンテナ:回り道日記
頭では理解できるDIコンテナ。ほんとに必要なのかいまいちわからない。でもEJBの効率の悪さを軽減解消するために使うことがちょっとわかりました。 開発効率の向上の事例も目にし、メリットを知りました。 メンテナンスが楽になるし設定も楽になるんです。 愛の国のあのお方もとても喜ばれておいででした。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://www.kt.rim.or.jp/~kbk/zakkicho/07//zakkicho0701.html
Amazon.co.jp: オブジェクト指向入門 第2版: 原則・コンセプト: バートランドメイヤー (著), 酒匂寛 (翻訳): 本
サービス終了のお知らせ
http://www.scl.kyoto-u.ac.jp/scl/appli/appli_manual/SUNWspro/WS6U2/ja/manuals/stdlib/user_guide/general/17_2.htm