アラン・ケイの「Is "Software Engineering" an Oxymoron?」 - Smalltalkのtは小文字です
UPDATE!!： id:propella さんがすばらしい翻訳を公開してくださいましたので、そちらをどうぞ 「ソフトウェア工学」は矛盾語法か？ "-- -- -- -- -- -- -- -- -- -- -- -- -- --" Is "Software Engineering" an Oxymoron? [PDF(勝手ミラー版)] タイトルの訳はよく分からないのですが「“ソフトウエア工学”は矛盾表現か？」みたいな感じでしょうか。 これは、Croquet（Squeak システム上に構築された仮想３Ｄ空間オーサリング用のフレームワーク。Qwaq 社による商用化もされている）の最初の公開バージョンのマニュアル（Croquet0.1.pdf）の付録に掲載された文章なのですが、なぜか公式サイトからは消えていて、ググって見つけた勝手アーカイブから入手できる元の PDF でも絵が壊れていたので、そ
オブジェクト指向の概念の発明者は誰ですか？ - Smalltalkのtは小文字です
忙しい人のためのまとめ 一般に「オブジェクト指向プログラミング」と呼ばれる考え方には発案者が異なる二系統がある。（ただし簡単のため、次のうち前者から批判的に派生して生じたプロトタイプベースのオブジェクト指向はここには含めていない） アラン・ケイによる、変化に強い長期運用可能な遅延結合システムを SIMULA67 にあった「オブジェクト」をメッセージの受け手とすることで実現（オブジェクトにメッセージ送信）するアイデアに基づく「メッセージングのオブジェクト指向」と、 ビアルネ・ストラウストラップ（前後して抽象データ型を発案したリスコフ本人、オブジェクトクラスを考えたニガードらSIMULA陣営、Eiffelのメイヤーらも同様の着想を得ている）による、ユーザー定義型（抽象データ型）を SIMULA67 にあった「クラス」という言語機能を使って実現（カプセル化、継承、多態性）するアイデアに基づく「抽
オブジェクト指向でなぜ作るのか を買ってみました - みねこあ
オブジェクト指向をわかりたいなら今すぐ『オブジェクト指向でなぜつくるのか』を読め -思っているよりもずっとずっと人生は短い。 VS お勧め本？ - カレーなる辛口Javaな転職日記 について、http://www.kt.rim.or.jp/~kbk/zakkicho/08/zakkicho0807c.html#D20080728-4 さんよりお呼びが掛かりました。 普段、さんざ召還魔法を使いまくっている私としては、ここは恩返しのしどころです。けれど、敵はあまりに強大で...。 オブジェクト指向でなぜつくるのか―知っておきたいプログラミング、UML、設計の基礎知識― 作者: 平澤章出版社/メーカー: 日経BP社発売日: 2004/06/03メディア: 単行本購入: 34人 クリック: 448回この商品を含むブログ (198件) を見る 結論から先に言えば、OO の入門書としては、本書はダメで
Tell, Don't Ask | The Pragmatic Bookshelf
This website uses cookies for account and order processing. By using this site you understand and agree to our use of cookies, our Terms Of Use, and Privacy Policy Alec Sharp, in the recent book Smalltalk by Example [SHARP], points up a very valuable lesson in few words: Procedural code gets information then makes decisions. Object-oriented code tells objects to do things. — Alec Sharp That is, yo
Javadocを書かない - しげるメモ
前回はJavadocを書く - しげるメモというタイトルで話を進めましたが、今回は逆にJavadocを減らすプラクティスについてメモがてら。 私は別にJavadocを書くのが好きなわけではなく、単純に書いたほうがめんどくさくないと思うのでそうしてます。ただ、Javadocを書くのもかなりめんどくさいとは自分自身で感じているので、そのめんどくささをできるだけ減らす道を現在も模索中です。 やり方としては単純で、次のうちどちらかです。 Javadocをそもそも書かない Javadocに書くことを減らす かなりの部分がEffective Java (Java Series)に紹介されているプラクティスとかぶりますが、ここではあくまで"めんどくさくないJavadoc"という視点でいきます。 Javadocをそもそも書かない If an API is to be usable, it must be
Java におけるコード進化パターン (Code Evolution Patterns in Java)
Java におけるコード進化パターン (Code Evolution Patterns in Java) asato shimotaki <asatohan at gmail.com> 最終更新日 : 2009/6/21 (2004/4/22 より) [...] For twenty years, I spent two or three hours a day looking at pairs of things -- buildings, tiles, stones, windows, carpets, figures, carvings of flowers, paths, seats, funiture, streets, paintings, fountains, doorways, arches, friezes -- comparing them, and asking my
OOコード養成ギブス - rants
Binstock on Software: Perfecting OO's Small Classes and Short Methods The Pragmatic Programmersシリーズの新しい本、The ThoughtWorks Anthologyの中に 興味をそそるエッセイがある。Jeff Bayの"Object Calisthenics"だ。 これは良いオブジェクト指向の性質を実証する小さなルーチンを書く方法をマスターするための 詳細にわたるエクササイズだ。オブジェクト指向なルーチンを書く能力を向上させたい開発者がいるなら このエッセイに目を通すことを勧める。ここにBayのアプローチを要約してみよう。 彼は次にあげられる制約のもとに1000行のプログラムを書くことを勧めている。 これらの制約は意図的に過剰な制限となっているが、これは開発者を手続き的なやり方から脱却させるた
オブジェクト指向をわかりたいなら今すぐ『オブジェクト指向でなぜつくるのか』を読め - 思っているよりもずっとずっと人生は短い。
オブジェクト指向の入門書と言えば『オブジェクト指向でなぜつくるのか』に決まってるよね、と話していたら、「ええ、そうなんですか？」と、この本に推薦のことばを寄せていた平鍋さんの会社の人に言われてショックでした。ちょっと駄目すぎです。角谷さんなんとかしてください（＜無茶振り）。 オブジェクト指向でなぜつくるのか―知っておきたいプログラミング、UML、設計の基礎知識― 作者: 平澤章出版社/メーカー: 日経BP社発売日: 2004/06/03メディア: 単行本購入: 34人 クリック: 448回この商品を含むブログ (198件) を見る 私もご他聞に漏れず、オブジェクト指向の本はいろいろ読んでみたのですが、『オブジェクト指向でなぜつくるのか』に勝る本は内外合わせてまだお目にかかれていません。率直に言ってプログラマ必読書だと思います。 その素晴らしさは随所にあるのですが、章立てに追って説明しましょ
5. オブジェクトの意味 - オブジェクト指向とは何か
オブジェクト指向とは何か2002-10-03「オブジェクト指向とは何か」この根源的な問いの答えはなかなか難しいものです。ここではその難しく哲学的な問題に真っ向から挑んでみたいと思います。 さて、オブジェクトというのは実世界にあるモノや概念のことであって、オブ ジェクト指向というのは実世界のモデリングであるという話をしました。今ま でのソフトウェア開発手法では最小単位は「処理」であってそれを説明するに は「どんな処理をするものか」を書いたのに対して、オブジェクト指向では最 小単位は「オブジェクト」であり、それを説明するには「それは何か」を書か なくてはなりません。 では、オブジェクトの意味するところ、いわゆる「それは何か」を書くために は何を書けばいいのでしょうか。それについてここで話をしたいと思います。 さて、単刀直入にオブジェクトの3つの意味を挙げましょう。例えば「犬」と いうオブジェク
静的オブジェクト指向は設計者が苦労を背負込むシステム
2009-09-26 北陸Scala第1回開催 2009-04-04 第十四回java-ja勉強会 - 第1回チキチキ 地方巡業withひがやすを飲み会in富山開催 2009-03-20 わんくま大阪勉強会#28 「ジェネリクスを使おう！」 2008-11-08 わんくま富山勉強会#1 開催 2008-08-09 わんくま東京勉強会#23 「C#登場前夜」 2008-04-01 *で始まるタイトルはエイプリルフールネタです 2008-01-26 わんくま東京勉強会#16 「ライブプログラミング」 2007-12-08 わんくま名古屋勉強会#1 「わんくま初めてのJava」 2007-07-28 開店 みねこあさんのところで挙がっていた、 静的オブジェクト指向と動的オブジェクト指向の軽さについての話題から。 Javaは経済的事情をうまく捉えて普及した プログラミングの効率と経済で書いていると
大人のためのブラックボックス読解講座――クロージャとオブジェクトの微妙な関係（その2）
大人のためのブラックボックス読解講座――クロージャとオブジェクトの微妙な関係（その2）：プログラミング言語の進化を追え（1/3 ページ） 前回に引き続き、Scheme言語の処理系、Gaucheを開発している川合史朗氏が、クロージャの機能を検証し、関数型言語とオブジェクト指向言語の関係について解説していきます。今回は、クロージャとオブジェクトのより深淵を探求します。 抽象化ツールとしてのクロージャ C++的なオブジェクトの世界では、オブジェクトの実体とは「ひとかたまりの構造体としてメモリ上に置かれたインスタンス変数の値」にすぎません。オブジェクトのポインタを取れば、それは事実上、その構造体へのポインタを持っていることになります。クロージャを「関数」中心で見ていると、その実体は「オブジェクト」の実体とは異質なもののように思えるでしょう。 確かにクロージャのナイーブな「実装」は、関数ポインタと環
JOINでパフォーマンスが下がるという幻想 - ぐるぐる～
テーブル結合でパフォーマンス低下って、あんまり経験ないんだけど…。 はてなブックマーク - これは・・・ - 予定は未定Blog版 なんてはてブコメントが付いていたけど、正規化されてて、きちんとしたインデックスが張られてるならJOINでパフォーマンス低下するようなことはそうそうないでしょうね。 問題は、正規化されていない巨大な「横持ち」のテーブルとかの場合。 正規化してはいけない、っていうのがRDBMS使う意味をなくしているんだけど、正規化してはいけないことによって生じる弊害がまさに「JOINでパフォーマンスが低下する」原因になるものばかり、ということで、そういう状況にない限りJOINによるパフォーマンス低下という状況には陥らないんじゃないかなぁ。 第1正規化がされていないと・・・ カンマ区切りやスペース区切りでひとつの「セル」に押し込む必要があり、カラムのサイズが大きくなりやすい WHE
オブジェクト指向 - ぐるぐる～
クラスを使っていればオブジェクト指向なんだと勘違いしてるやつ多すぎ。 意味もなくgetter/setter用意してるやつ多すぎ。 未だにシステムハンガリアン使ってるやつ多すぎ。 カプセル化=データ隠蔽だと思ってるやつ多すぎ。 継承を実装の継承のためだけに使ってるやつ多すぎ。 ・・・もうやめて。
Smalltalk - Wikipedia
Smalltalk（スモールトーク）は、Simula のオブジェクト（およびクラス）、LISPの徹底した動的性、LOGO のタートル操作や描画機能に、アラン・ケイの「メッセージング」というアイデア[2]を組み合わせて作られたクラスベースで手続き型の純粋オブジェクト指向プログラミング言語、および、それによって記述構築された統合化プログラミング環境の呼称。 Smalltalk で一語であり、「Small Talk」「SmallTalk」などは誤りである。 大規模な開発実績としてはCargill Lynx Project[3]があり、国産製品の開発実績としてはMCFrameがある。 概要[編集] 開発の経緯[編集] ゼロックスのパロアルト研究所（PARC）で1970年代に約10年かけ3世代（Smalltalk-72、76、80）を経て整備された。当初は、ダイナブックである Alto（アルト） の
引き算の難しさ - しんさんの出張所 はてなブログ編
フレームワークを作っている人にはいつもあるひとつのジレンマがあるんじゃないでしょうか。 それは機能追加によるフレームワークの肥大化です。 フレームワークのジレンマ これはフレームワークに限ったことではないですね．任天堂が10年以上もソフトメーカーとしてトップを君臨し続けている理由がここだったりします．引き算がすごいうまいのです．足し算で機能を追加することは安易に考えてしまいますが，そうすると続編では前提の知識が必要になり敷居があがる．事実上PS2で崩壊したゲームソフトってのはどれもそんな問題を抱えていたりした． ドラゴンクエストだって１は一人旅ということで敷居はかなり低かった．２は魔法も使えない一人旅でスタート．慣れてきたところで魔法が使える仲間が加入し，さらに進むと範囲魔法を使う仲間が現れる．３では職業や魔法が大幅に増えて敷居が大幅に増えてしまい，コアなユーザーには非常に評価が高いものの
フレームワークのジレンマ - おおたに6号機blog
フレームワークを作っている人にはいつもあるひとつのジレンマがあるんじゃないでしょうか。 それは機能追加によるフレームワークの肥大化です。 ユーザさんから言われた機能・自分達のチームでこれは良い！と思って入れた機能など 理由はそれぞれですが、フレームワークが形になってからの機能追加は進む一方です。 機能が増えればそれだけ故障箇所が増えるのと一緒です。また想定しない使い方をユーザさんが してくる場合もあるでしょう。 自分もこのような機能追加は正しい・求められているんだとずっと思っていました。 今でも間違ったことだと思ってるわけではありません。 ただし、それには大きな前提があることにちょっとだけ気づいたのです。 それは、 最初に開発されたフレームワークの機能は十分に検討され、 厳選されたミニマルセットな機能以外はあってはならない。 という前提です。書いてみれば当たり前で拍子抜けされるかもしれませ
萩原正義のソフトウェア工学論（1）
ソフトウェア開発が抱える問題を工学的なアプローチで解決しようとする試みが長く続けられてきた。しかし現状では成功しているとは言えない。現場での適用を難しくしている大きな要素がソフトウェア技術の進化の方向性だ。技術は実装に近い段階から生まれるためソフトウェア開発全般で活用するにはそれなりの時間がかかる。個々の技術論にとらわれすぎず，開発全体を見渡す大きな視点を持つべきだ。（本誌） ソフトウェア開発の成否は，開発にかかわるメンバーの人間的な要素に大きく左右される。プロジェクト管理や，システムに対する顧客の要求の抽出，開発メンバー間での情報共有や合意。メンバー同士の円滑なコミュニケーションや，モチベーションの維持も必要だ。 これらは，技術者個々の知識や経験に依存する部分が多い。だからソフトウェア開発には属人性があり，開発者によって品質と生産性に大きな差が出る。これだと納期や開発コストを適切に見積も
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
はてなブログ | 無料ブログを作成しよう
http://mikata.curiocube.com/oop/part2/ch16_whatsobject.html
プログラミング言語論（小野）ノート。