1から始めるRuby - hp12c
ブログを下記に移転しました。デザイン変更により移転先では記事が一層読みやすくなっていますので、よろしければ移動をお願い致します。 1から始めるRuby : melborne.github.com - 数学の世界で1は数である 3歳の子供でもそれを知っている そして私やあなたが老いて死にゆくまで 1は数であり そこに疑念の入る余地はない プログラミングの世界でもふつう 1は数である CでもJavaでもHaskellでも 1は数であり それ以上でもそれ以下でもない ところが驚くべきことに Rubyの世界では 1は数ではないのである 嘘だと思うなら irbを立ち上げて 次のようにしてみるといい $ irb >> 1.next => 2 あなたは今 1にnextというメッセージを送った そうしたら1は 2という答えを返したのだ つまりRubyの世界で 1は数以上のものであり メッセージに返答する「
継承という手段 - みねこあ
ポリモーフィズムは継承の面白い副作用..なんかじゃない - みねこあ のコメント欄より。田辺さんとのやり取りで、私が相当おかしなことを言っている件について。 「インターフェイス継承」という言葉が、仕様を引き継ぐことなのか、Java の Interface のような 実装をまったく含まないクラスからの継承を指すのかが曖昧に感じられるため、前のエントリではお茶を濁していたのですが、これは本質ではなく、さらなる混沌とモヤモヤ時空を作り出してしまっています。また脳内知識だけで書いてしまったための「嘘」も見受けられます。その結果、新たな オレオレOOP を作り出さんとばかりな、感じになっていて、これは非常によくないです。だめだめだ、あたし。 なので、ちゃんと「インターフェイス継承」と「実装継承」で説明しようと思いました。まず「インターフェイス継承」の、誤解を呼ばない別のいい表現がないかな、と捜してみ
データ構造はクラスに任せた！だから、アルゴリズムはstatic関数で書くぜ！！（キリッ - みねこあ
きむら(K)さんち経由、実はオブジェクト指向ってしっくりこないんです！。いろいろ強烈なインパクトが満載で、スルーできませんでした。 特に「メンバー関数をstatic宣言すればインスタンス宣言をしなくてもいい」ということ知ってからは、メンバー関数を従来のファンクションのように使っている。共有変数も、pubulic static宣言していまう。したがってプロパティなんて作らない。 staticを理解していない人のコードを見ると、いちいちインスタンス宣言しているので笑ってしまう。 ぎゃーっ....。本人はまわりを笑っているつもりでも、逆にまわりに嗤われていますよ、絶対。 ここ以外にも突っ込みどころ満載のエントリーですので、読みながら突っ込むお手々が止まらなくって、腕がつりそう。そんな突っ込み連打なエントリーもおもしろそうですが、わたしはそういうのは上手く書けないので（性格がネチっこいから、なんだ
プロトタイプベースの誤解 - Smalltalkのtは小文字です
クラスベースのOOとプロトタイプベースのOOで決定的に違うのは、プログラムを動かしている最中にオブジェクトが出来ること、すなわちメソッド(method)を追加したり再定義したりできるかだ。 404 Blog Not Found:タイプ・クラス・プロトタイプ - OOの語彙 これはひどい。ｗ オブジェクトに対して動的（実行時）にメソッドやインスタンス変数を追加できることと、“プロトタイプベース”においてオブジェクトがそれが属するクラスによらず独自のメソッドやインスタンス変数を持てることとは別の話です。 あらためて、「プロトタイプベース」という用語自体に問題が多いことを実感させられる記事でもありますね。個人的には、クラスを用いないオブジェクト生成手法の話でないのならば（つまり、「プロトタイプの複製でオブジェクトを生成する」ことが話の本筋でないならば）「プロトタイプベース」ではなく、「インスタン
テニスの取得ゲーム状況 - Smalltalkのtは小文字です
キミのコードが汚い理由 − ＠IT をうけた、Haskell 脳その他の方々による Ruby 版などを拝見。 sshi.Continual - 美しいコード？ 趣味的にっき - テニスの勝負判定コード Tommy Heartbeat 2nd - 美しいプログラムコードとは。 バカが征く - めんどいからRubyで書くけど… それぞれに興味深かったので、私なりのメッセージング脳だとどのようになるのか、Smalltalk 版と、それをほぼ直訳した Ruby 版を書いてみました。 まずベースとなる Smalltalk 版をメタ情報を除いた加工コードで（ファイルイン不可）。 Object subclass: #TennisSetScorer instanceVariableNames: 'games' TennisSetScorer >> initialize games := Dictionar
まつもと直伝 プログラミングのオキテ---目次 - まつもと直伝 プログラミングのオキテ：ITpro
第0回 あらためてRuby入門 まつもとゆきひろ氏自身による「Ruby入門」をお届けします。日経Linuxの連載開始前の特別企画（2005年4月号）として，Rubyが他のスクリプト言語やオブジェクト指向言語とどこが違うのか，なぜ便利なのかを中心に解説してもらったものです。 ● 基本と他言語との違い ● 実装とRuby誕生の秘密 第1回 プログラミングとオブジェクト指向の関係 プログラマを目指す人々の中にも，「オブジェクト指向は難しい」とか，「なかなか分からない」という印象を持つ方が多いようです。そこで，Rubyを題材にオブジェクト指向という考え方について説明していきます。 ● その1 ● その2 ● その3 第2回 抽象データと継承 オブジェクト指向プログラミングを構成する3原則のうち，前回は「ポリモーフィズム」を学びました。今回はオブジェクト指向の歴史を復習した後，残りの「データ抽象」と
Open-Closed Principle とデザインパターン
1999/09/03 更新 石井 勝 さて，このセクションではデザインパターンを統一的に理解するために，「 Open-Closed Principle (OCP) 」 という設計ルールに基づいてパターンを眺めてみることにします．まず OCP の意味と解説を行い，その後デザインパターンを OCP の観点から見てみます．実は，デザインパターンのうちの多くは OCP を満たすために用意されたものと考えることができるのです．このセクションでは， OCP を理解し，数あるデザインパターンの中からどういう場合にどのパターンを使うのが一番効果的なのかを考えます． GoF のデザインパターンは，全部で 23 個ものパターンがあります．このデザインパターンは，多くの局面で繰り返し現れる設計を抽出したものですから，オブジェクト指向のエッセンスを集めたものだと言えるでしょう．オブジェクト指向には，カプセル化
オブジェクト指向の法則集
1999/07/07 更新 石井 勝 はじめに ここでは，オブジェクト指向に出てくる法則・原則をまとめました．パターンに比べてほとんど知られていないのが現状ですが，優れたオブジェクト指向開発者を目指すならデザインパターンよりまずこっちを理解し覚えてしまいましょう． これらの法則は，絶対守らなければならないというものではありません．開発中に法則が守られているか意識することが重要です．つまり 今行っている設計はその法則が守られているだろうか その法則を破っている場合，破るべき正当な理由があるだろうか と絶えず考えるようにしましょう．そうするとそれは自然に優れたオブジェクト指向設計になるのです．つまりこれらの法則は，優れたオブジェクト指向開発のための指針なのです． Robert C. Martin の Principles of OOD Robert C. Martinは，オブジ
FizzBuzzをオブジェクト指向にしよう - 矢野勉のはてな日記
Java, FizzBuzz id:yojikさんからトラックバックをいただきました。こちらを読んでて、逆に純度100%のOO厨気分で考えるとどうなるか考えてみた。まずOO厨な考え方では「結果」を先を求める。1から100まで並んでるんだけど3の倍数の所は「Fizz」で、5の倍数のときはBuzzで、両方の倍数の場合はFizzBuzzが並んでる、FizzBuzzな仕様の「シーケンス」があればいい。シーケンス=繰り返し。ならばIteratorだ。いまさらFizzBuzz問題をOO厨がやるとどんなことになっちゃうのか - yojikのlogなるほど....面白い。 FizzBuzz問題の発端となった記事の「２分」に惑わされていて、自分でこの遊びに思い至らなかったのが口惜しい。Lispの件だってもはや「２，３分で」なんて話はどっかにすっとんじゃってて、「Lisp的にはどうやるか」という方向にシフトし
[PDF] On the Duality of Operating System Structures
Hållbar omställning och konkurrenskraft på vetenskaplig grund
![[PDF] On the Duality of Operating System Structures](https://cdn-ak-scissors.b.st-hatena.com/image/square/19a294a034a35ba9de191a76839408ae76d7b5ef/height=288;version=1;width=512/https%3A%2F%2Fwww.ri.se%2Fsites%2Fdefault%2Ffiles%2Fstyles%2Ffull_width_opengraph%2Fpublic%2F2022%2F11%2FHallbar-omstallning-for-konkurrenskraft.png)
Cで実現する「ぷちオブジェクト指向」：CodeZine
はじめに CodeZineではお初にお目にかかります、επιστημη（エピステーメー）です。最初のアーティクルはクラシックなCのお話。 昨今のアプリケーションはオブジェクト指向言語による実装が主流と言ってもいいでしょう。C++、Java、VB.NETさらにはRubyやPythonといったスクリプト言語まで、オブジェクト指向でない言語を探すのに苦労するくらいです。 本記事では、今なお現役バリバリで活躍している手続き型言語の代表格（？）Cによる、オブジェクト指向のマネゴト（オブジェクト指向風味のCコーディングスタイル）を試みます。対象読者 もっぱらCを主な開発言語として使ってはいるけども、オブジェクト指向に興味と憧れを抱いている方。抽象データ型 手始めにオブジェクト指向の特徴の1つ、「抽象データ型（ADT：Abstract Data Type）」をCで実現してみます。抽象データ型とは、データ
enum-j.html#java_enum
C言語によるプログラミングでは、列挙型(enum型)はたいへん良く使われます。 オブジェクト指向言語でも、それは変わらないようです。C言語を拡張したC++言語ではもちろん、Java言語でも、J2SE 5.0になってから列挙型が導入されたほどです。 その一方で、オブジェクト指向言語で列挙型を使う弊害も、繰り返し指摘されてきました。列挙型とswitch文を使ったソースコードは、ポリモーフィズムを使って書き直すべき典型的な悪い例として、しばしば取り上げられて来ました。 しかし、列挙型を使ったプログラムのすべてが、ポリモーフィズムを使って書き直すべきだとは限りません。継承によるポリモーフィズムは、オブジェクト指向の特徴の１つですが、サブクラスを作るべきではないケースもあるのです。そのような場合に、列挙型を使ったコードを書くことは、悪いことではありません。 ここでは、オブジェクト指向言語における列挙
Kazuho@Cybozu Labs: setTimeout をオブジェクト指向にしてみる
« Japanize - Opera9に対応しました | メイン | Firefox Developers Conference での質疑応答メモ » 2006年12月14日 setTimeout をオブジェクト指向にしてみる setTimeout と setInterval が window オブジェクトのプロパティなのは、それがブラウザの機能であって言語処理系自体の機能でないことを考えれば当然だと思います。しかし、それがゆえかに、this が引き継げなかったり、IE では引数が渡せなかったりといった不便があります。どうせだったら、こうなっていたらよかったのにね、ということで、Function.prototype をイジってみました。すでにありそうなネタですが (苦笑) Function.prototype.applyTimeout = function (ms, self, args)
perltoot - トムによるPerlオブジェクト指向チュートリアル パッケージ モジュール
名前¶ perltoot - トムによるPerlオブジェクト指向チュートリアル 概要¶ Object-oriented programming is a big seller these days. Some managers would rather have objects than sliced bread. Why is that? What's so special about an object? Just what is an object anyway? オブジェクト指向プログラミングは、昨今の、ビッグセラーです。 マネージャーには、薄切りパン(訳註：良い発明のこと)よりもむしろオブジェクトを持ちたがる人もいます。 どうしてでしょうか? オブジェクトの、何がそんなに特別なんでしょうか? そもそも、オブジェクトとは一体なんでしょうか? An object is nothing
404 Blog Not Found:オブジェクトは難しくない。難しいのはクラス
2006年11月16日16:55 カテゴリLightweight Languages オブジェクトは難しくない。難しいのはクラス 大人だからオブジェクトは難しくなる。子供にとっては実はオブジェクトは自然で自明で簡単だ。 オブジェクト指向を正しく理解する：ITpro オブジェクト指向はしばしば，とっつきづらく難しい技術と言われます。その理由の一つには，対象とする分野が広く，それぞれに深みがあることが挙げられます。しかし，それ以上にこの技術を難しくしている落とし穴とも言うべき原因が二つあると筆者は考えています。それは比喩を乱用する説明の仕方の問題と，「もの中心」を意味するコンセプト自体の問題です。事実、オブジェクト指向というのは最初は子供向けだったのだ。 このことを、現在「オブジェクトとはなんぞや」という大人たちは忘れてしまっている。 それで、オブジェクトとは何か、といえば、「自分が何が出来る
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Perlゼミ(サンプルコードPerl入門)
サービス終了のお知らせ