タグ

OOに関するmoroのブックマーク (3)

  • Rails、あんたなんか嫌いよ - Rails での OO 設計について - tomykaira makes love with codes

    2013-06-25 Rails、あんたなんか嫌いよ - Rails での OO 設計について ruby rails 最近はずっと Rails 書いてるんですが、書けば書くほど嫌いになってくるんです。 倦怠期的なやつなんですが、 Rails さんの悪いところばっかり見えてきて、もう一緒にいたくないんです。 でも別れるほどじゃないし… という愚痴にみせかけた Rails での設計についての議論です。 長いけどコードは一切出てこないので通勤中にでもよんでください。 注意 一部にはげしい言葉遣いがでてくるので、読んで不快になるかもしれません。 不快になったとしても責任は負いかねます。 次のような方の期待に沿う結論はでません。残念でした。 Sinatra, Padrino の人 関数型の人 静的型付けの人 C の人 TL;DR Rails にだまされない。 自分の道を見定める。 欺瞞にみちた Ra

    moro
    moro 2013/06/25
    よい話。ふつうにつくるのが大事で大変ですよねーっていう。アプリ書くときにフレームワーク()書こうとしない。このごろは、そこにあるべくしてある自然なコードが書きたいです。
  • いまさらながらだけど、オブジェクトとクラスの関係を究めてみようよ - 檜山正幸のキマイラ飼育記 (はてなBlog)

    オブジェクトとクラスの関係について、次のような説明を見かけました(文言の引用ではなくて、檜山による要約)。 オブジェクトとクラスは全体としてツリー構造をしていて、ツリーの末端をオブジェクト、末端以外のノードをクラスという。末端であるオブジェクトは、その親ノードであるクラスのインスタンスと呼び、クラスどおしの親子関係を継承関係と呼ぶ。 うーむ、この説明、ある意味「簡潔でわかりやすい」とも言えるのだけど、ちょっと単純化し過ぎでしょ。 オブジェクトやクラスの概念て、そんなに美しくもなきゃ、整合的でもありません。実用性やら実装上の都合やらでゴチャゴチャですがね。しかし、そのゴチャゴチャが悪いともいえません。ゴチャゴチャを無理に単純化することなく、必然性を持った(幾分は偶発的だけど(苦笑))複雑さとして理解すべきかと思います。 というわけで、メタクラスやレイフィケーション(reification)な

    いまさらながらだけど、オブジェクトとクラスの関係を究めてみようよ - 檜山正幸のキマイラ飼育記 (はてなBlog)
    moro
    moro 2008/01/09
  • 連載:.NETで始めるデザインパターン 第7回 デザインパターンの落とし穴(1/2) - @IT

    これまでの連載では、既存の実装コードに対してリファクタリングを行っていくと、自然な成り行きでデザインパターンが導かれていくことを説明してきた。このことが示すとおり、デザインパターンは<有能な設計者のみが行える特殊な>デザインではない。むしろ、<オブジェクト指向で設計する者がその最適な解を求めるうえで当然の帰結として用いられる普遍的な>デザインなのである。つまり、デザインパターンを覚えておくということは、この解にすばやく到達できるということを意味する。 それでは、覚えておいたデザインパターンを、自由気ままにあらゆる場所で何にでも適用していくという態度は正しいだろうか。もちろんそんなわけはない。デザインパターンを適用するのにふさわしくないケース(個所)があるのだ。従って、上手にデザインパターンを使いこなすためには、そういった個所、つまり「デザインパターンの落とし穴」を避けて通る必要があるのだ。

  • 1