勉強が苦手な人向けの「遅延評価勉強法」 : ロケスタ社長日記
はじめに 遅延評価勉強法という言葉があります。 これはamachangというjavascrpitを書く人で有名な技術者の方が、ブログで言ってた言葉です。該当するエントリは以下。 遅延評価的勉強法 - IT戦記 - これは、おいらが考える「効率のいい勉強法」に近いものがあるので、少しまとめてみました。 あくまで主観的に「いい」と思っている勉強法ですが、参考になれば、、 遅延評価勉強法って？ まず、以下のサイトがすごくまとまってるので引用してみます。 「遅延評価」という言葉を調べてみると、「ある式を、その結果が本当に必要になる時点までは評価しないでおくテクニック」とあります。そのメリットは、「条件次第で捨ててしまうような値を事前に準備することは非効率的である。このような場合遅延評価を行うと必要なときだけ値が計算されるので計算量を低減できる」とありました。 ここから遅延評価勉強法とは、「その知識
プロトタイプベースの誤解 - Smalltalkのtは小文字です
クラスベースのOOとプロトタイプベースのOOで決定的に違うのは、プログラムを動かしている最中にオブジェクトが出来ること、すなわちメソッド(method)を追加したり再定義したりできるかだ。 404 Blog Not Found:タイプ・クラス・プロトタイプ - OOの語彙 これはひどい。ｗ オブジェクトに対して動的（実行時）にメソッドやインスタンス変数を追加できることと、“プロトタイプベース”においてオブジェクトがそれが属するクラスによらず独自のメソッドやインスタンス変数を持てることとは別の話です。 あらためて、「プロトタイプベース」という用語自体に問題が多いことを実感させられる記事でもありますね。個人的には、クラスを用いないオブジェクト生成手法の話でないのならば（つまり、「プロトタイプの複製でオブジェクトを生成する」ことが話の本筋でないならば）「プロトタイプベース」ではなく、「インスタン
いまさらながらだけど、オブジェクトとクラスの関係を究めてみようよ - 檜山正幸のキマイラ飼育記 (はてなBlog)
オブジェクトとクラスの関係について、次のような説明を見かけました（文言の引用ではなくて、檜山による要約）。 オブジェクトとクラスは全体としてツリー構造をしていて、ツリーの末端をオブジェクト、末端以外のノードをクラスという。末端であるオブジェクトは、その親ノードであるクラスのインスタンスと呼び、クラスどおしの親子関係を継承関係と呼ぶ。 うーむ、この説明、ある意味「簡潔でわかりやすい」とも言えるのだけど、ちょっと単純化し過ぎでしょ。 オブジェクトやクラスの概念て、そんなに美しくもなきゃ、整合的でもありません。実用性やら実装上の都合やらでゴチャゴチャですがね。しかし、そのゴチャゴチャが悪いともいえません。ゴチャゴチャを無理に単純化することなく、必然性を持った（幾分は偶発的だけど(苦笑)）複雑さとして理解すべきかと思います。 というわけで、メタクラスやレイフィケーション（reification）な
Java の「インターフェイス」という機能の元ネタ - Smalltalkのtは小文字です
具体的な言語処理系というわけではありませんが、おそらくこれが元ネタだろうというアイデアが記された論文は見つかりました。もっともゴスリングが Java や Oak（Java の前身…というか初期バージョンそのもの。変わったのは名前だけなので）について書いたものに Java のインターフェイスは○○を参考にして考えた…という記述を見つけられずにいるので、これをＦＡとするには、もう少し調査が必要そうですが、とりあえずということで。 Interfaces for strongly-typed object-oriented programming (1989) - ダウンロードは有料 この論文中では、たとえば Point というインターフェイスを定義して、それを実装した polar_point というクラスを定義する例として、仮想言語を用いてこんなコードが示されています。 interface Po
ポリモーフィズムは継承の面白い副作用..なんかじゃない - みねこあ
なんか微妙な話の流れに。 3. 同時に考えなければならないことを減らせること （中略） オブジェクト指向プログラミングの学習にスコープを移せば、ポリモーフィズムと継承が絡まない動的言語を使って学んだ方が、格段に楽だと思います。ポリモーフィズムのことを考えるときはポリモーフィズムのことだけ、差分プログラミングのことを考えるときには差分プログラミングのことだけを考えていられます。 難しい言語 - みねこあ に、 ポリモフィズムと継承は表裏一体なので，片方だけを考えるのはむしろおかしい． 「難しい言語」の補足 - カレーなる辛口Javaな転職日記 ときて、同コメント欄で、 >ポリモフィズムと継承が表裏一体の概念 えーっと，「表裏一体の概念」とは書いていませんよね．「表裏一体で使用する」の方が適切かと．定義上は関係ない概念であったとしても，実際に使用する上で表裏一体で使用するので十分に柔軟で実用的
Matzにっき(2006-01-27)
<< 2006/01/ 1 1. [教会] 元旦 2 1. 出産 2. 帰省 3. 到着 3 1. デジタル体重計のユーザインタフェース 4 1. [OOP] Classbox 2. [OOP] Classboxの実装 5 1. 帰宅 2. PCレスライフ 6 1. PC修理 7 1. 雪かき 2. [言語] プログラミング言語SRU 8 1. [教会] 断食安息日 2. あーめん 3. 筋肉痛・体調不良 9 1. 米子 10 1. [原稿] オープンソースマガジン3月号 11 1. [原稿] 日経Linux 3月号 12 1. [Ruby] Charming Ruby Compiler 2. [Ruby] The Open Nature Of Ruby 13 1. ニート娘に悩む親 2. Python Status Update 3. 泥縄 14 1. 宣教師のお手伝い 2. Simpl
オブジェクト指向は構造化の「次」か? : 404 Blog Not Found
2006年01月27日16:54 カテゴリLightweight Languages オブジェクト指向は構造化の「次」か? Matzさんがこう言うのは以外な気がする。 Object Oriented Perl Damian Conway Matzにっき(2006-01-20)実際には、オブジェクト指向プログラミングは、構造化プログラミングの「次」と 認識されるべきものだと思う(OOAやOODのことは知らんけど)。 というのも、「オブジェクト指向」は「構造化」の進化系ではなく、元来直交して扱える概念だからだ。 実際smalltalkやhypertalk、そしてsqueakといったプログラミング環境では、オブジェクトはフィールドとかボタンとかといった、「もろに目に見える」「実存」であり、それ故まだものごとを抽象化して捉えることの出来ない子供でも始められるようになっている。 実はすでに適切に設計
「オブジェクト指向神話」神話 - Matzにっき(2006-01-20)
<< 2006/01/ 1 1. [教会] 元旦 2 1. 出産 2. 帰省 3. 到着 3 1. デジタル体重計のユーザインタフェース 4 1. [OOP] Classbox 2. [OOP] Classboxの実装 5 1. 帰宅 2. PCレスライフ 6 1. PC修理 7 1. 雪かき 2. [言語] プログラミング言語SRU 8 1. [教会] 断食安息日 2. あーめん 3. 筋肉痛・体調不良 9 1. 米子 10 1. [原稿] オープンソースマガジン3月号 11 1. [原稿] 日経Linux 3月号 12 1. [Ruby] Charming Ruby Compiler 2. [Ruby] The Open Nature Of Ruby 13 1. ニート娘に悩む親 2. Python Status Update 3. 泥縄 14 1. 宣教師のお手伝い 2. Simpl
神様ルートクラスを嫌い、POJOを好む：An Agile Way：オルタナティブ・ブログ
ぼくがオブジェクト指向言語を勉強しはじめた90年ころは、「継承」という概念がとても流行っていて、継承によって「差分プログラミング」ができることがオブジェクト指向設計の再利用性の典型例のように言われていた。もちろん、こういう誤解は95年くらいには、みんなウソだと分かってきていた。 しかし、それでもときどき、 すべてのクラスの頂点のような「神様クラス」を作ってしまうことがある。 例えば、90年代の多くのC++オブジェクト指向データベースは、Persistenceのようなクラスを継承することで永続オブジェクトとなるクラスをマーキングしたり、あるベンダーのコレションクラスは、Objectというクラスを継承したクラスのオブジェクトのみがコレクションの要素となることができたり、という具合に。また、EJBも最近まではEntityBeanを継承することでEntityBeanの資格が得られるし、Servel
The Rational Edge （オブジェクト指向を超えて） ― ＠IT
The Rational Edgeより：元ソフトウェア開発者のGary Pollice教授は、オブジェクト指向の概念を最初から学ぶコンピュータサイエンスの学生は、構造化プログラミングテクニックが染み込んだプログラマーより、これらをソフトウェア開発プロジェクトに応用するときに苦労しないと指摘する。本稿では構造化とオブジェクト指向の考えを考察し、オブジェクト・ファーストの教授法のメリットを解説して、アスペクト指向のプログラミング手法が普及する中でのアスペクト・ファースト・アプローチへの移行の可能性を考えてみたい。 筆者は、大学生のころ初めて携わったハイテク系の仕事の1つに関連し、ALGOLのサブセットを学習するクラスに1日参加しただけで4Kバイトのメモリを搭載したコンピュータをプログラムできた。筆者は、気象計算処理を実装するのに十分な文法を学んだのだ。いま思い出すと、マシンを制御して自分の命令
まつもと直伝プログラミングの掟1(1) プログラミングとオブジェクト指向の関係（上）：IT Pro
プログラマを目指す人々の中にも，「オブジェクト指向は難しい」とか，「なかなか分からない」という印象を持つ方が多いようです。そこで，Rubyを題材にオブジェクト指向という考え方について説明していきます。（ネットワーク応用通信研究所 まつもと ゆきひろ） プログラミングとは，コンピュータに作業手順を教え込むことです。ただ，コンピュータは決して賢くないので，言われた通りの作業をこなすことしかしません。コンピュータが優れているように見えるのは，単に超高速で計算する能力があるからです。効率の悪い作業を命じられても，プログラムによって指定された通り，文句の一つも言わずに黙々と処理します。コンピュータの能力を生かすも殺すもプログラムの書き方ひとつなのです。 ですから，プログラムを書く人（プログラマ）はコンピュータを自分の意のままに扱う人であり，コンピュータの「ご主人様」であると言ってもよいでしょう。にも
青木淳「オブジェクト指向システム分析設計入門」
はじめに この本はオブジェクト指向技術を利用してソフトウェア開発することを目指す技術者および管理者のために書かれた本です。プログラムのコードや難しい数式などを排除してあり，図と文章によって基本概念や適用技術を平易に解説しています。オブジェクト指向技術を数学(形式)ぬきで探求する試みといえるでしょう。 本来，オブジェクト指向技術を，瓶から瓶へ水をもらさぬように，正確に伝えるには，数学(型理論)を必要とします。数学的形式化が行われていないと，オブジェクト指向で表面化する問題の議論がかみ合わず空転することが多いからです。あの時はこうだっだ，この時にはああだったと経験則の披露になりかねないのです。やはり何かしらの形式化は必要でしょう。しかし，数学的形式化の苦しみときたら並大抵ではありません。特に，後述するインヘリタンス(継承) や並列などが絡んだあかつきには残酷なのです。私だけかもしれません
ナチュラルなコードとは？：An Agile Way：オルタナティブ・ブログ
題名は、音楽の話に聞こえるかもしれませんが、ソフトウェア開発の話です。 以前、咳さんが体験談として >「お前のコードはナチュラルでエレガントだ」 >と言われた時は うれしかったなあ と語ってくださったことから、ちょっと思い起こしてみました。「ナチュラルなコード」とはなんだろうか、ということを考えてみたい。ぼくは、何かの本かインタビューで読んだ、Ward Cunningham の言葉がとても強く印象に残っています。 ...(要約するとこんな感じ)... そのコードは、すばらしいコードだった。ソースリストをプリンタに出力すると、 それは、「どこからでも読み始めることができ、意図が明確だった」 ............................ 「どこからでも読み始めることができる」（！）というのは、オブジェクト指向のよいコードの特徴じゃないだろうか。 （以前、oosquare-ml だっ
「保守しやすい」ことが、良い設計(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年のコンテクストでは）。 再利用性では
Java のクラスはオブジェクトじゃない?! - Smalltalkのtは小文字です
関連：id:sumim:20040525:p1 keisuken さんの 航海日誌 発、babie さんの 遅レス 経由で、オライリーのオープンソースコンベンション（OSCON 2005）のセッション「10 Things Every Java Programmer Should Know About Ruby」（スライド、brazil さんの和訳）で語られた「Item #9 Everything is an Object」から生じる語弊について。 そうですね。これではまるで Java のクラスがオブジェクトではないかのように読めますし、そうだとすれば（オブジェクトに定義にもよりますが、おそらく）間違いでしょう。ただ、文脈をたぐると、ここでの Jim Weirich さんの主張は「（Ruby において）“Array”は、Array というクラス（を実現した）オブジェクトを束縛した定数（に過ぎ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
サービス終了のお知らせ
Tociyuki::Diary
ブラックジャックのオブジェクト指向開発
mamezou.net