やっと理解できた！JSオブジェクト指向プログラミング再入門 | ゆっくりと…
既に多くの方が JavaScript のオブジェクト指向的側面についての解説を記事にされていますが、読み手側から見ると、例えばプログラミング言語への習熟度やオブジェクト指向自体に対する理解度がマチマチなわけで、私自身、「おお、なるほど！」 っていう、頭の中のスイッチがパチンッ！と入るような境地には達していませんでした。 かつて私も オブジェクト指向なJavaScriptプログラミングのススメ なんていう翻訳記事を書いてはいるのですが、正直なところ prototype.constructor の存在は知りませんでしたし、Function.call や Function.apply をどう使えばよいのかなどをちゃんと理解できてはいませんでした。 そんな中、2011年12月に書かれた Doc Center | Mozilla Developer Network の記事 オブジェクト指向 Java
オブジェクト指向について語った時に使ったメモ
今日、オブジェクト指向について1時間ほど語りました。整理するため自分用に書いたメモを公開します。大まかな構成はメモどおりに話しましたが、メモに書いていないこともたくさん話していますし、書いていても話さなかったこともあります。 前提として自分自身のオブジェクト指向へのスタンスを書いておきます。 自分のプログラマとしてのキャリアとオブジェクト指向の隆盛の重なりを考えると客観的に見て自分はオブジェクト指向世代のプログラマなんだと思います。一方で、世間で過剰にもてはやされる技術には反発してきました。オブジェクト指向も例外ではありません。オブジェクト指向を否定はしませんが、金科玉条のように扱う人の前では、オブジェクト指向なんて技法のひとつに過ぎないと、冷たく突き放してきました。 ただここ数年、かつてに比べてオブジェクト指向の威光は下がっている気がします。関数型プログラミング支持者から、オブジェクト指
第4回 オブジェクト指向の本質 | gihyo.jp
エンジニアとして良い仕事をするために必要なこと ソフトウェア業界で日米を往復しながら仕事をしていると、世界中のさまざまなエンジニアに会う。私のように「プログラミングを心底楽しんでいる」人から、「新3K」（きつい・厳しい・帰れない）を身をもって体験している人までさまざまだが、共通して言えることは、エンジニアとしての基礎がしっかりできている人とできていない人では、その生産効率に大きな開きがあり、それが結果的には、会社での労働環境や待遇に、そして結果として自分自身にとっての「仕事の充実度」に、大きな影響を与えているということである。 いつも締め切りに追われている、毎回バグで苦しんでいる、徹夜の連続で体力に限界がきているなど、「仕事がきつい」理由はいろいろとあると思うが、会社や上司の悪口を言う前に、自分自身がプロフェッショナルなエンジニアとしてこの業界で勝負をするうえで必要な最低限の基礎がで
最近もらった本: インターフェイス指向設計 - steps to phantasien t(2008-07-21)
最近でもないですが頂きました. ありがとうございます > 関係者の方. 多忙にかまけて感想を書くのが遅れてしまいました. 遅れた理由はもう一つあって, 私はこの本の主張があまりピンとこなかった. でも貰った本のことを単にイマイチだったと書くのも社会人としてどうかなー, などとよたよたするうちに月日は流れ... 嘘や間違いはない. けれどアジャイルなオブジェクト指向設計という視点でみると, いまいち relevance を欠く気がする. この本を読んでまずい設計が良くなるのを期待できない自分がいる. 何でピンとこないのか, しばらく考えていた. どうも "インターフェイス" を中心に据えるのがまずいんじゃなかろうか. オブジェクト指向の設計を議論する上で, インターフェイスはツールの一つに過ぎない. "インターフェイス指向設計" という切り口は, 極端に言えば "クッキー指向ウェブアプリケー
継承を禁忌すること - Radium Software
IS-A IS-A HAS-A - Raganwald IS-STRICTLY-EQUIVALENT-TO-A - Raganwald OOP に関する書籍を読むと，たいてい「継承は軽々しく使うべきではない」というようなことが載っている。「継承は IS-A の関係にのみ使うべき」とか，「実装の共有に継承を使ってはならない」とか，「継承よりも合成・包含を優先すべき」とか……。 それが Raganwald に言わせれば，「IS-A の関係は HAS-A の関係と同じこと」とか，「継承は便利機能に過ぎない」とか，「リスコフの置換原則さえ生ぬるい」というような厳しい意見にまでなる（こんな風に言い切ってはいないけれど……まあ，そのようなことを丁寧に説いている）。 このような，制限の無い継承を禁忌する意見は，一般に納得することのできる内容ではある。ただ，それを現場で適用するのは，非常に難しいことのよう
L'eclat des jours(2008-05-22) インターフェイス
_ インターフェイス 角谷さんから『インターフェイス指向設計』を献本してもらったので、薄いってこともあって、大体読んだ（つもり）。 インターフェイス指向設計 ―アジャイル手法によるオブジェクト指向設計の実践(Ken Pugh) ぱらぱら読んだ限り、悪くない。むしろ手軽さからは良いのではなかろうか（落とし穴はあるかも知れないから、そこはがっつり読み込んだわけではないので断言はできない）。 まず、この本は普通にUMLを使いたい人（そうでない人は規格本を読むと良いのではなかろうか）で、良く使い方がわからない人の役に立つ。ファウラーの薄いUMLの本も良いけど、これもいいね。少なくとも、シーケンス図、状態遷移図、クラス図、ユースケース図は押さえられる。設計するには、とりあえずそれだけ書ければ十分だ （コンポーネント図と配置図は、UML2で微妙になってしまったしなぁ）。 でも、ちょっと思ったが、この本
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行のプログラムを書くことを勧めている。 これらの制約は意図的に過剰な制限となっているが、これは開発者を手続き的なやり方から脱却させるた
業務アプリには関数と構造体だけあればいい件について - yojikのlog
たけぞうさんやひがさんの古いエントリをよんでいまさら考えてみました。 http://www3.vis.ne.jp/~asaki/p_diary/diary.cgi?Date=20070128#2007012800 http://d.hatena.ne.jp/higayasuo/20070129#1170052662 関数と構造体しか無い、いわゆる構造化設計*1だと、上位の関数が下位の関数に処理を委譲して・・・みたいな感じで、機能のツリー構造が出来上がる。このような構造では必然的に、上位レベルの関数が下位レベルの関数(のインタフェース)に依存することになると思う。上位の関数が、下位の関数の面倒見る*2から。(追記: 厳密には関数を持つモジュールのツリー構造が出来あがる) ならば下位の関数のインタフェースをカッチリ決めれ! といわれそうですが、なんだかんだで下位の関数こそ変更されやすいのが業務
2007-01-29
デブサミ-VisualBasic, Delphiから10分でJava+Flex2にポーティング http://d.hatena.ne.jp/higayasuo/20070118#1169099987 Flex2では、モデルとUIコンポーネントと間の自動バインディングがサポートされています。自動バインディングとは､モデルの値が更新されたら自動的にUIコンポーネントの表示が更新されたり､UIコンポーネントに入力している値が変わったら､自動的にモデルの値を更新する機能です。 デフォルトではバインディングは単方向です。基本的には､モデルの変更をUIコンポーネントが検知するだけ。例えば､次のようなMXMLがあったとします。 <?xml version="1.0" encoding="utf-8"?> <![CDATA[ [Bindable] private var hoge:String; ]]>
[ 技術講座 ] Domain-Driven Designのエッセンス 第1回｜オブジェクトの広場
DDD難民に捧げる Domain-Driven Designのエッセンス 第1回 ドメイン駆動設計とは 株式会社オージス総研 アドバンストモデリングソリューション部 佐藤 匡剛 Domain-Driven Design Tackling Complexity in the Heart of Software Eric Evans 著 Addison-Wesley, 59.99ドル 560ページ ISBN: 0-321-12521-5 「ドメインモデリング」は、アプリケーション開発において最も重要な部分だとされています。しかしその割には、フレームワークの使い方やアーキテクチャの設計方法など技術に関する解説書はたくさんあるものの、ドメインモデリングそのものを扱った書籍はほとんど無かったと言ってもいいでしょう。Eric Evansの『Domain-Driven Design』（以降DDD）は、「
Why Arc Isn't Especially Object-Oriented
なぜArcはとりたててオブジェクト指向でないのか---Why Arc Isn't Especially Object-Oriented--- Paul Graham Copyright 2002 by Paul Graham. これは、Paul Graham：Why Arc Isn't Especially Object-Oriented を、原著者の許可を得て翻訳・公開するものです。 <版権表示> 本和訳テキストの複製、変更、再配布は、この版権表示を残す限り、自由に行って結構です。 (「この版権表示」には上の文も含まれます。すなわち、再配布を禁止してはいけません)。 Copyright 2002 by Paul Graham 原文: http://www.paulgraham.com/noop.html 日本語訳：Shiro Kawai (shiro ＠ acm.org) <版権表示終り
Rees Re: OO
著者: Jonathan Rees 原文: http://www.paulgraham.com/reesoo.html 日本語訳：Shiro Kawai (shiro ＠ acm.org) これを翻訳したのは2004年7月頃だったのだが、 このメッセージについてRees氏に訳文公開の許可を求めたところ、 「あれは急いで書いたemailなので、きちんとした論になっていない。 できれば書き直したいと思っている。ただいつ出来るかわからないので、 私からのメイルがしばらく無かったら公開してもらって構わない」 との返事をもらった。それからもう半年経つので、公開することにした。 ただ、読む場合は著者本人が上記のように思っていることを留意して頂きたい。 また、原文が書かれたのは2002年であることにも注意。 いくつかの事実は古くなっているかもしれない。 2005/01/23 翻訳公開 「なぜArcはとり
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
IBM Developer
Amazon.co.jp: オブジェクト指向入門 第2版: 方法論・実践: バートランドメイヤー (著), 酒匂寛 (翻訳): 本
Amazon.co.jp: アジャイルソフトウェア開発の奥義 第2版 オブジェクト指向開発の神髄と匠の技: ロバート・C・マーチン (著), 瀬谷啓介 (翻訳): 本
Amazon.co.jp: SMALLTALKで学ぶ オブジェクト指向プログラミングの本質: 青木淳, 浅岡浩子, 澤本依里: 本
Amazon.co.jp: インターフェイス指向設計 ―アジャイル手法によるオブジェクト指向設計の実践: Ken Pugh (著), 角谷信太郎(監訳) (翻訳), 児島修 (翻訳): 本
ドメインモデル管理のあらゆる側面
Amazon.co.jp: ジェネレーティブプログラミング: クシシュトフチャルネッキ (著), ウールリシュ W.アイセンアッカー (著), 津田義史 (翻訳): 本
IBM Developer
