タグ

programmingとoopに関するtekehikoのブックマーク (6)

  • 第4回 オブジェクト指向の本質 | gihyo.jp

    エンジニアとして良い仕事をするために必要なこと ソフトウェア業界で日米を往復しながら仕事をしていると、世界中のさまざまなエンジニアに会う。私のように「プログラミングを心底楽しんでいる」人から、「⁠新3K」(⁠きつい・厳しい・帰れない)を身をもって体験している人までさまざまだが、共通して言えることは、エンジニアとしての基礎がしっかりできている人とできていない人では、その生産効率に大きな開きがあり、それが結果的には、会社での労働環境や待遇に、そして結果として自分自身にとっての「仕事の充実度」に、大きな影響を与えているということである。 いつも締め切りに追われている、毎回バグで苦しんでいる、徹夜の連続で体力に限界がきているなど、「⁠仕事がきつい」理由はいろいろとあると思うが、会社や上司の悪口を言う前に、自分自身がプロフェッショナルなエンジニアとしてこの業界で勝負をするうえで必要な最低限の基礎がで

    第4回 オブジェクト指向の本質 | gihyo.jp
  • 最近もらった本: インターフェイス指向設計 - steps to phantasien t(2008-07-21)

    最近でもないですが頂きました. ありがとうございます > 関係者の方. 多忙にかまけて感想を書くのが遅れてしまいました. 遅れた理由はもう一つあって, 私はこのの主張があまりピンとこなかった. でも貰ったのことを単にイマイチだったと書くのも社会人としてどうかなー, などとよたよたするうちに月日は流れ... 嘘や間違いはない. けれどアジャイルなオブジェクト指向設計という視点でみると, いまいち relevance を欠く気がする. このを読んでまずい設計が良くなるのを期待できない自分がいる. 何でピンとこないのか, しばらく考えていた. どうも "インターフェイス" を中心に据えるのがまずいんじゃなかろうか. オブジェクト指向の設計を議論する上で, インターフェイスはツールの一つに過ぎない. "インターフェイス指向設計" という切り口は, 極端に言えば "クッキー指向ウェブアプリケー

    tekehiko
    tekehiko 2008/07/22
    ある視点からは隠された実装の詳細には, 別の視点にとっての抽象の核が潜んでいる. この複眼的な視点で設計するソフトウェアはどんな姿になるのだろうか.
  • 継承を禁忌すること - Radium Software

    IS-A IS-A HAS-A - Raganwald IS-STRICTLY-EQUIVALENT-TO-A - Raganwald OOP に関する書籍を読むと,たいてい「継承は軽々しく使うべきではない」というようなことが載っている。「継承は IS-A の関係にのみ使うべき」とか,「実装の共有に継承を使ってはならない」とか,「継承よりも合成・包含を優先すべき」とか……。 それが Raganwald に言わせれば,「IS-A の関係は HAS-A の関係と同じこと」とか,「継承は便利機能に過ぎない」とか,「リスコフの置換原則さえ生ぬるい」というような厳しい意見にまでなる(こんな風に言い切ってはいないけれど……まあ,そのようなことを丁寧に説いている)。 このような,制限の無い継承を禁忌する意見は,一般に納得することのできる内容ではある。ただ,それを現場で適用するのは,非常に難しいことのよう

    継承を禁忌すること - Radium Software
  • Amazon.co.jp: ジェネレーティブプログラミング: クシシュトフチャルネッキ (著), ウールリシュ W.アイセンアッカー (著), 津田義史 (翻訳): 本

    Amazon.co.jp: ジェネレーティブプログラミング: クシシュトフチャルネッキ (著), ウールリシュ W.アイセンアッカー (著), 津田義史 (翻訳): 本
  • 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行のプログラムを書くことを勧めている。 これらの制約は意図的に過剰な制限となっているが、これは開発者を手続き的なやり方から脱却させるた

    OOコード養成ギブス - rants
    tekehiko
    tekehiko 2008/04/27
    OOPについての具体的で明確な指針。
  • 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はとり

    Rees Re: OO
    tekehiko
    tekehiko 2008/03/15
    『C/C++プログラマにとってオブジェクト指向は第一級の関数に類するものが存在しない世界からの開放であったのに対し、Lispプログラマにとっては(中略)牢獄になる』
  • 1