オブジェクト指向のソースを読むのが難しい理由 - 都元ダイスケ IT-PRESS
ダラダラ書かない予定だよ。ざっくり行くよ。あと、分かってる人には当たり前な事だと思うよ。 あるクラスについて知りたかったら、まずその基底クラスを知れ 例えば、Integerクラスについて知りたいと思ったら、Integer.java だけを読んでいてはダメだ。確かに「Integerに特化した責務・構造・操作」は読み取れるかもしれないが、数値としての基本的な責務・構造・操作はNumberに書かれている。それを読まずして、Integerが保つ数値という一面を知ることはできない。Integer.javaには「Integer - Number」*1の情報しか書いてないのだよ。差分プログラミング。 さらに、忘れちゃいけない。Object.javaを読め。全ての道は暗黙的にObjectにつながっている。Objectを知らずしてJavaのクラスを知る事は絶対にできない。Objectなんて、みんな「知った気
new を不当に貶める陰謀と JavaScript におけるクラスの継承構造の話 - vivid memo
私は陰謀論者じゃないですし JavaScript の new 演算子が大好きなわけでも大嫌いなわけでもないです。 念のため。 本記事は Hiraku さんが書かれた下記記事への言及です。 newを封印して、JavaScriptでオブジェクト指向する(1) newを封印して、JavaScriptでオブジェクト指向する(2) newを封印するべき4つの理由 new 演算子は使うな!? 「newを封印するべき4つの理由」 でも new がいかに糞であるかが書かれていますし、その記事からも言及があるように Crockford さんが書かれた書籍 『JavaScript: The Good Parts ―「良いパーツ」によるベストプラクティス』 でも new 演算子は Bad Parts に分類されています。 new 演算子が忌避される理由はいろいろあるみたいですが、Hiraku さんの記事では n
newを封印するべき4つの理由
ちょっと勢いに任せて書いちゃったので攻撃的な文章になってます。。 すごくわかりやすい解説記事を頂いたので、こちらも必読です。 new を不当に貶める陰謀と JavaScript におけるクラスの継承構造の話 - vivid memo (追記：2011/5/15) 前の記事「newを封印して、JavaScriptでオブジェクト指向する」が思いのほか反響が大きかったので、調子に乗って補足を書いてみますよ。 ブコメへの返信 「無用な複雑化に見える。」「俺俺オブジェクト指向な気がする。」といったご意見もいただいたんですが、普通たった１０行の関数でオレオレオブジェクト指向なんて作れないですよ…。JavaScriptの内部機構をほとんどそのまま使っているからこそ、この行数で済むのです。 それに、このプロトタイプ的継承の考え方をDouglas Crockfordが編み出したのは、もう５年も前の話です。E
カーネギーメロン大学コンピュータサイエンス学科、1 年次のカリキュラムから OO を除外 | スラド デベロッパー
ストーリー by reo 2011年03月29日 12時00分 2 単位の講義は 90 時間なんですぜ ? 部門より カーネギーメロン大学のコンピュータサイエンス学科は 1 年次のカリキュラムからオブジェクト指向プログラミングの講義を除外したそうだ (本家 /. 記事より) 。 大学側曰く「オブジェクト指向プログラミングは非モジュール的で非並行処理であるというその性質が現代のコンピュータサイエンスのカリキュラムに適さないと判断し、初年度のカリキュラムから完全に除外することを決めた」とのこと。オブジェクト指向プログラミングは 2 年次に「オブジェクト指向デザインメソッド」という選択講義として提供されるとのことだ。なお、この学科では初年度に関数プログラミングと命令型プログラミングの新しい講義が組み込まれ、これらを必修科目としてデータ構造およびアルゴリズムの新たな講義が計画されているとのことだ。
JavaScriptにおけるオブジェクトの定義 - Islands in the byte stream (legacy)
JavaScriptで一番簡単にオブジェクト指向プログラミングを行う方法 (id:perlcodesample) 私は特にJavaScriptに詳しいわけではなく、オライリーの『JavaScript』、通称サイ本を読んだ程度なのですが、私の知るかぎりJavaScriptでオブジェクト*1を定義する方法には二つの軸があります。一つ目はオブジェクトの生成方法で、二つ目はメソッドの与え方です。すなわち： new演算子で生成する / オブジェクトリテラルで生成する prototypeによってメソッドを生やす*2 / プロパティを直接代入してメソッドを生やす これについて具体的に説明してほしいとのことでしたので、以下にこの二つの軸の組み合わせ、計4つの方法を示します。 (実行可能なコードはjsdo.itにて： http://jsdo.it/gfx/9LR3) var pointToString =
はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
継承は害悪か。
くっくっkura 🇯🇵🦀 @PG_kura OOP で継承は害悪だとは思うけども、実際に継承を言語から消去したとして一般 PG に受け入れられる言語になり得るだろーか。
ハタさんのブログ(復刻版) : Scala の trait って便利だよね。って話
Scala Advent Calendar jp 2010の 12/20 を担当しました。Day 14です。 よろしくお願いします。 色々何か書こうか迷ったけど、traitについて書こうと思います。 scalaのtraitって、インタフェースのようでありながら実装を持てるので、色々便利ですよね。 javaからscalaと移行してきた人にとってtraitとはなんぞや？と思ってしまうので、そのあたりを書いてみようかと思います。 Slateによるtrait まず、traitだけを見ると、scalaのtraitは他の言語のソレと違っています。 例えが悪い(?)ですが、traitを持つSlateという言語(SELF系の言語で、small talkによく似ている言語です) の場合、traitはどちらかというと、メソッドの集合であって、そのtraitを使うことで多重継承等を行うようにできるヤツです
多重継承はC++の用語として不適切
C++の規格上、派生と継承は、明確に区別するべきであることはすでに述べた。 本の虫: abstract classで知らなかったこと、付記、派生と継承の違い ところで、「多重継承」という言葉がある。これは、Multiple Inheritance（複数の継承）という言葉の一般的な訳語である。多重継承は、実はC++には相応しくない言葉である。クラスは派生（derive）するものであって、継承（inherit）するものではないからである。 規格ではどうなっているかというと、Multiple base classes（複数の基本クラス）となっている。規格の文章は多重継承という言葉を使っていない。ただし、注記として、「複数の基本クラスを使うことは、しばしば多重継承と呼ばれている」などと書いてある。つまり、通称として多重継承という言葉が一般的であるということに言及しているのだ。 また、すでに書いてい
"ポリモーフィズム==ガチャピンチャレンジ"説 - ka-ka_xyzの日記
コラム「システムエンジニア 生き残りの極意」でちょっとした祭りになっている件 - babydaemonsの日記 ポリモーフィズム（多態性）を知らずにオブジェクト指向という単語を口にするなー！！！ という悲痛な叫びを読んでふと思い出したのでメモ。 以前、会社の技術者向け新人研修でJavaを教えたとき、ポリモーフィズムの概念を理解してもらうときに使った例え。 「ポリモーフィズム==ガチャピンチャレンジ」説 要は、ガチャピンの着ぐるみ（Javaで言うインターフェイス）に"何かチャレンジしろ"というメソッドを定義する。「中の人」が入れ替わることで、"何かチャレンジしろ"というメソッドを実行したときの処理内容は変化するけど、視聴者（呼び出し元）から見れば「中の人」がスキーヤーだろうが格闘家だろうがレースドライバーだろうが、全てひとくくりに「ガチャピン」として扱うことが出来るので便利。ひたすらifで処
オブジェクト指向プログラミングは間違いだったか?
原文(投稿日：2010/07/12)へのリンク 「メッセージ送信を行うSmalltalk-80から生まれたオブジェクト指向を振り返って、継承などの現在の状況を見てみれば、私たちは間違った道を下ってきたと言えるだろうか?」 これは、QCon London 2010 インタビュー の最初の質問だった。このインタビューを受けたのは、Erlangの最初の開発者であるJoe Armstrong博士とSmalltalk、OOP、パターンに長い間関係しているRalph Johnson博士だ。私たちは「間違った道」を当てもなくさまよってきたが、これはオブジェクトの考え方の実現方法に欠点があったためであり、この考え方自体の欠点ではないと2人は述べた。実際に、Ralph Johnson博士は以下の点から始めた。 あるアイデアを思いついて世の中に出すと、たいていの人にとって急進的過ぎるのはよくあることです。大半
ボク、if文。わるいモンスターじゃないよ！ - 都元ダイスケ IT-PRESS
id:aroundthedistance に召還されたぜ。 http://d.hatena.ne.jp/aroundthedistance/20100727/1280227851 …その昔なー。Seasar Conferenceで「あなたのコードからnewとifが消えます、魔法のDI」みたいなセッションをした。今思い出して「釣りすぎたぜサーセン」という気分になったことをまず懺悔しておく。 この doBusinessん中のif〜else ifをなんとかしたい。 …（中略）… ちょっとすっきりした。けどまだifが残ってるよね。 ポリモーフィズムの例をもうちっと実用的に書いてみた。 - 都元ダイスケ IT-PRESS どんだけif文悪者なんだ。そこまで嫌ならば、一度もif文を書かずにコードを書けばいい。無理だがなｗ と自嘲。 if文に限らず、問題になるのは濫用なのだ。"ある知識"がトッ散らかって
JavaScriptのnewって何？一体何なの？という話 - 愛と勇気と缶ビール
マクラ JavaScriptを使っている人なら知っていることだろうけど、JavaScriptはプロトタイプベースのオブジェクト指向を採用しているので「クラス」がない。オブジェクトしかない。 でも、組み込みの演算子としてnewがあって、それを使って var obj = new Object(); とか書けちゃう。クラスってものはJavaScriptにはないはずなのに、new ClassName();と書くとあたかもClassNameクラスのオブジェクトのインスタンスが生成され、それが返ってくるかのような挙動をしている。 これは気持ち悪い。言語仕様としてはクラスは本来存在しないのに、クラスのようなものが導入されている。まともな神経を持った人間なら、一体new演算子って何なの？という疑問を持つのが当たり前である。「{}はnew Object()のシンタックスシュガーです」とか言ってふんぞり返って
ヽ( ・∀・)ノくまくまー(2010-06-28) [Smalltalk] 第21回 Smalltalk勉強会「Traits」
Traits て何？ いくつかのメソッドを定義しておいて、他のクラスに取り込む方法 (メソッド群の継承機構) Rubyのmoduleみたいなもの？ そう。ほぼそれ。ScalaだとTrait 大概の言語にあるよね？ うん。Perl6だとRoleらしい そして、JavaだとInterface! 違う。それだけは違う ちょｗ。なんでよ！差別イクナイ！ JavaはAPI定義のみで実装がないから ああ、API+実装がTraitsなのか そう。言語ごとに違いがある(追加方法、衝突管理、状態、継承)ので、そう言い切るのも火種になる なるほど。ぢゃ、*大筋で*「API+実装がトレイト」と思っていればOK？ うん、完璧。Smalltalk実装のTraitsと区別するためにカタカナにしたものナイス えへへ。あ、でさ、さっきの衝突管理って何？ 同じメソッド名がある場合にどうなるか問題 ああ、Ruby の強制上書
オブジェクト指向の概念の発明者は誰ですか？ - Smalltalkのtは小文字です
忙しい人のためのまとめ 一般に「オブジェクト指向プログラミング」と呼ばれる考え方には発案者が異なる二系統がある。（ただし簡単のため、次のうち前者から批判的に派生して生じたプロトタイプベースのオブジェクト指向はここには含めていない） アラン・ケイによる、変化に強い長期運用可能な遅延結合システムを SIMULA67 にあった「オブジェクト」をメッセージの受け手とすることで実現（オブジェクトにメッセージ送信）するアイデアに基づく「メッセージングのオブジェクト指向」と、 ビアルネ・ストラウストラップ（前後して抽象データ型を発案したリスコフ本人、オブジェクトクラスを考えたニガードらSIMULA陣営、Eiffelのメイヤーらも同様の着想を得ている）による、ユーザー定義型（抽象データ型）を SIMULA67 にあった「クラス」という言語機能を使って実現（カプセル化、継承、多態性）するアイデアに基づく「抽
Hello World
読みにくいので貼り付けてみると、こんな感じ。すごくパターンハッピーですね。気持ちはわかります。オブジェクト指向デザインパターンを覚えると必要ないところにまで使いたくなるんですよね、なぜか。なんか必殺技っぽいからでしょうか。 /* http://developers.slashdot.org/comments.pl?sid=33602&cid=3636102 */ public interface MessageStrategy { public void sendMessage(); } public abstract class AbstractStrategyFactory { public abstract MessageStrategy createStrategy(MessageBody mb); } public class MessageBody { Object paylo
apply/call での継承の話 - nothing but trouble
この件について。 http://d.hatena.ne.jp/iskwn/20091215/1260828978 継承というかスコープがわかりやすいというのもメリットだと思うけど、カプセル化しやすいのも大きなメリットかなと思う。 function Foo(){} (function(){ var bar = 'bar'; this.bar = bar.toUpperCase(); function baz () { console.log('baz'); } this.baz = function() { baz(); console.log('BAZ'); } }).call(Foo.prototype); function Bar(){} Bar.prototype = new Foo(); (function() { this.hoge = 'hoge'; this.baz = fu
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://twitter.com/mattn_jp/status/28366429491