Binstock on Software: Perfecting OO's Small Classes and Short Methods The Pragmatic Programmersシリーズの新しい本、The ThoughtWorks Anthologyの中に 興味をそそるエッセイがある。Jeff Bayの"Object Calisthenics"だ。 これは良いオブジェクト指向の性質を実証する小さなルーチンを書く方法をマスターするための 詳細にわたるエクササイズだ。オブジェクト指向なルーチンを書く能力を向上させたい開発者がいるなら このエッセイに目を通すことを勧める。ここにBayのアプローチを要約してみよう。 彼は次にあげられる制約のもとに1000行のプログラムを書くことを勧めている。 これらの制約は意図的に過剰な制限となっているが、これは開発者を手続き的なやり方から脱却させるた
関連：[OOP] オブジェクト指向の概念の発明者は誰ですか？ くだんのオブジェクト指向３点セットの元になったともくされる論文のメモ。抽象データ型に加えて、以下の機構がオブジェクト指向プログラミングをサポートするのに必要とされる。 特殊な関数呼び出し機構（仮想関数、動的結合） 型チェック機構 継承機構 多重継承機構 アクセスコントロール機構 以上は５点ですが、ここから静的型言語（あるいは C++ ）に特異的な３点（型チェック機構、多重継承機構、アクセスコントロール機構）が拒絶されて「抽象データ型＋ 継承・動的結合」となったのち、「カプセル化、継承、多態性」に変化して定着したものと思われます。アクセスコントロール機構は、いったんは拒絶されたものの、第１項の“抽象データ型”が“カプセル化”に言い換えられるようになったのを契機に、これに組み込んでも（組み込まなくとも）よい…ということになったのでし
h003149b さん(?)の「SchemeとActor理論」 http://www.ice.nuie.nagoya-u.ac.jp/~h003149b/lang/actor/actor.html こうして改めてアクターによるプログラミングを見ると、そこで要求されるメンタルモデルが Smalltalk-72 のそれとそっくりであることに驚かされますね。 ところで、オブジェクト指向の成り立ちに触れた文章では、よく、オブジェクト指向（この文脈では、おそらくケイのオブジェクト指向。つまり「メッセージング」）は、アクター理論から（後に）派生して生じたものである…というような記述を多く見かけるのですが、これもまたオブジェクト指向にまつわる数ある“常識のウソ”（id:m-hiyama さん、お気をつけて！ｗ）のひとつで、実際は逆、つまりケイのメッセージングのアイデアが、ヒューイットのアクター理論につな
「ＯＯ（ＯＯＰ）とは何か？」については、ネタが割れてしまえばそんなに複雑なものではない…と個人的には最近、考えるようになってきています。 リスコフのユーザー定義型（aka、抽象データ型。データと手続きのセット）そのもの、あるいはその「ユーザー定義型」をクラスやそれに準ずる機能で実現しようとするＯＯ（ストラウストラップ。aka、クラス指向。継承を使ったプログラミング）。もしくはそれらを一般化したＯＯ（クック。aka、手続きによる抽象化）。 メッセージングにより動的性を実現しようとするＯＯ（ケイ。aka メッセージ指向） 今回登場した、後者のメッセージングのＯＯのミニマリズムをおしすすめることによって派生的に生じたＯＯ（アンガーとスミスからの 派生 変形。aka、プロトタイプベースＯＯ。フレームとスロット、あとは委譲機構があれば十分…というミニマル化の結果、アンガーとスミスの頃には重要だった“
忙しい人のためのまとめ 一般に「オブジェクト指向プログラミング」と呼ばれる考え方には発案者が異なる二系統がある。（ただし簡単のため、次のうち前者から批判的に派生して生じたプロトタイプベースのオブジェクト指向はここには含めていない） アラン・ケイによる、変化に強い長期運用可能な遅延結合システムを SIMULA67 にあった「オブジェクト」をメッセージの受け手とすることで実現（オブジェクトにメッセージ送信）するアイデアに基づく「メッセージングのオブジェクト指向」と、 ビアルネ・ストラウストラップ（前後して抽象データ型を発案したリスコフ本人、オブジェクトクラスを考えたニガードらSIMULA陣営、Eiffelのメイヤーらも同様の着想を得ている）による、ユーザー定義型（抽象データ型）を SIMULA67 にあった「クラス」という言語機能を使って実現（カプセル化、継承、多態性）するアイデアに基づく「抽
はじめに この本はオブジェクト指向技術を利用してソフトウェア開発することを目指す技術者および管理者のために書かれた本です。プログラムのコードや難しい数式などを排除してあり，図と文章によって基本概念や適用技術を平易に解説しています。オブジェクト指向技術を数学(形式)ぬきで探求する試みといえるでしょう。 本来，オブジェクト指向技術を，瓶から瓶へ水をもらさぬように，正確に伝えるには，数学(型理論)を必要とします。数学的形式化が行われていないと，オブジェクト指向で表面化する問題の議論がかみ合わず空転することが多いからです。あの時はこうだっだ，この時にはああだったと経験則の披露になりかねないのです。やはり何かしらの形式化は必要でしょう。しかし，数学的形式化の苦しみときたら並大抵ではありません。特に，後述するインヘリタンス(継承) や並列などが絡んだあかつきには残酷なのです。私だけかもしれませんが，得
以下のコードはwell-formedである。 struct Non_abstract { virtual void f() { } } ; struct Abstract : Non_abstract { void f() = 0 ; } ; abstractクラスは、abstractクラスではないクラスから派生されることができる。その際、pure virtual functionではないvirtual functionを、pure virtual functionとしてオーバーライドすることができる。 これが何の役に立つのか分からない。ただ、pure virtual functionがあればabstract classであるなどという、あまり文法的に美しくないC++の仕様からすると、わざわざこの挙動を禁止する理由が見当たらなかったのだろうか。 ところで、今まで私は、派生と継承の違いを明確
エンジニアとして良い仕事をするために必要なこと ソフトウェア業界で日米を往復しながら仕事をしていると、世界中のさまざまなエンジニアに会う。私のように「プログラミングを心底楽しんでいる」人から、「新3K」（きつい・厳しい・帰れない）を身をもって体験している人までさまざまだが、共通して言えることは、エンジニアとしての基礎がしっかりできている人とできていない人では、その生産効率に大きな開きがあり、それが結果的には、会社での労働環境や待遇に、そして結果として自分自身にとっての「仕事の充実度」に、大きな影響を与えているということである。 いつも締め切りに追われている、毎回バグで苦しんでいる、徹夜の連続で体力に限界がきているなど、「仕事がきつい」理由はいろいろとあると思うが、会社や上司の悪口を言う前に、自分自身がプロフェッショナルなエンジニアとしてこの業界で勝負をするうえで必要な最低限の基礎がで
某所のチャットで話題になって、流れ去りそうだったのでもったいないから転載しておいた。事後承諾で。 MIYAMOTO Daisuke: 型の継承と実装の継承を区別する方法がないんだよな。 西尾泰和(nishio.hirokazu): 型を継承させずに実装を継承させたい→それ移譲で ってことかな？ MIYAMOTO Daisuke: そそ。そもそも、クラスに「型としての役割」と「実装としての役割」という複数の責務があることに、俺は長い間気づかなかった。これに気づかないと、型継承と実装継承が頭の中で整理できない。 西尾泰和(nishio.hirokazu): 僕が最近気づいたことも加えると、クラスには「ユーザ定義型」「インスタンスを作成する道具」「実装の再利用の単位」という3つの役割がある。 MIYAMOTO Daisuke: あぁ、インスタンスの生成器ね。 西尾泰和(nishio.hiroka
第6回は「名前のない品質とパターン言語」と題して、建築家アレグザンダー（Christopher Alexander）の「名前のない品質」“QWAN―Quality Without a Name”を紹介しました。この名前のない品質を建築の世界でどのように実践すればよいか、アレグザンダーはそのための1つの技法として「パターン言語」を提唱しました。このパターン言語のアイデアに注目し、ソフトウェアの世界に持ち込まれたのが、1つはデザインパターンをはじめとする「ソフトウェアパターン」の潮流です。もう1つの流れはケント・ベックが提唱したXP（eXtream Programming）をはじめとする「アジャイル開発」の潮流です。 パターンやパターン言語とオブジェクト指向とはまったく異なる概念ですが、ソフトウェアパターンはなぜかオブジェクト指向開発の世界に入ってきました。今回は「パターンとパターン言語入門」
わたしの以前のエントリー中の 例えば、カモノハシ本 の5章では、エイトクイーンパズルを解いていますが、これは Queen オブジェクト自体に「取られない位置に進む」「この位置を自分が攻撃できるか？を答える」という責務を持たせる Queen を各列に一づつ置く 端から順にQueen に「取られない位置に進め」をさせる。 という解き方をしています。各Queen は自らの位置の解を自ら解きます。 （中略） Board というオブジェクトは必ずしも必要ないですし、連結リストの一番端には現実には存在しない「番兵」を置く場合もあります。なによりも、Queen の駒が現実で勝手に自分の攻撃されない位置を求めて動くなんてありません。（そんなチェス盤を開発してくれ、という要件ではないのです） つまり、これは現実の写像ではありません。でも良いデザインです。 憂鬱本レビューの補足 - みねこあ について、わから
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く