いまさらながらだけど、オブジェクトとクラスの関係を究めてみようよ - 檜山正幸のキマイラ飼育記 (はてなBlog)
オブジェクトとクラスの関係について、次のような説明を見かけました（文言の引用ではなくて、檜山による要約）。 オブジェクトとクラスは全体としてツリー構造をしていて、ツリーの末端をオブジェクト、末端以外のノードをクラスという。末端であるオブジェクトは、その親ノードであるクラスのインスタンスと呼び、クラスどおしの親子関係を継承関係と呼ぶ。 うーむ、この説明、ある意味「簡潔でわかりやすい」とも言えるのだけど、ちょっと単純化し過ぎでしょ。 オブジェクトやクラスの概念て、そんなに美しくもなきゃ、整合的でもありません。実用性やら実装上の都合やらでゴチャゴチャですがね。しかし、そのゴチャゴチャが悪いともいえません。ゴチャゴチャを無理に単純化することなく、必然性を持った（幾分は偶発的だけど(苦笑)）複雑さとして理解すべきかと思います。 というわけで、メタクラスやレイフィケーション（reification）な
オブジェクト指向の概念の発明者は誰ですか？ - Smalltalkのtは小文字です
忙しい人のためのまとめ 一般に「オブジェクト指向プログラミング」と呼ばれる考え方には発案者が異なる二系統がある。（ただし簡単のため、次のうち前者から批判的に派生して生じたプロトタイプベースのオブジェクト指向はここには含めていない） アラン・ケイによる、変化に強い長期運用可能な遅延結合システムを SIMULA67 にあった「オブジェクト」をメッセージの受け手とすることで実現（オブジェクトにメッセージ送信）するアイデアに基づく「メッセージングのオブジェクト指向」と、 ビアルネ・ストラウストラップ（前後して抽象データ型を発案したリスコフ本人、オブジェクトクラスを考えたニガードらSIMULA陣営、Eiffelのメイヤーらも同様の着想を得ている）による、ユーザー定義型（抽象データ型）を SIMULA67 にあった「クラス」という言語機能を使って実現（カプセル化、継承、多態性）するアイデアに基づく「抽
はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
疑りぶかいあなたのためのオブジェクト指向再入門
このページは、「オブジェクト指向再入門」とあるように、 オブジェクト指向を勉強しようとして挫折した人向けの文書です。 タイトルに「疑り深いあなたのための」とありますが、 これは決して揶揄して言っているわけではありません。 現在世間に蔓延しているオブジェクト指向の説明では、 むしろ納得しない方がまともだとさえ思えます。 「オブジェクト指向を使えば、生産性が飛躍的に上がり、 プログラムの見通しがよくなり、再利用性も高まる」と聞かされて、 「ホントかあ?」と思える人は、一度読んでみてください。 本稿の対象読者は「既に他の手続き型言語を習得しているが、 オブジェクト指向が理解しがたいと感じている人」です。 言語としてはJavaを使用します。 手続き指向型の言語の例としては、C言語を使用します。 特にCに習熟している必要はないようにしたいのですが、 Cで言うところの「構造体」「ポインタ」「動的メモリ
矢沢久雄の早わかりGoFデザインパターン(1) | 日経 xTECH（クロステック）
今回は、パターンを1つだけ紹介します。「Mediatorパターン」です。GoF本では、それぞれのパターンの「目的]「背景」「効果」などが明示されています。私も、ちょっと真似をしてみましょう。複数のオブジェクトを組み合わせてプログラムの機能を実現するという目的において、オブジェクト間の関連がゴチャゴチャになってしまうという背景（問題）があり、Mediatorパターンの採用によって関連をキレイに整理できるという効果があります。説明だけでは、何のことだかわからないと思いますので、具体例をお見せしましょう。 図1[拡大表示](1)をご覧ください。これは、UML（Unified Modeling Language、ユーエムエル）と呼ばれる表記法で記述されたプログラムの設計図です。UMLでは、四角形の中に下線付きで名前を書いてオブジェクトを表し、関連のあるオブジェクトを矢印で結んで示します。ここで関連
満足せる豚。眠たげなポチ。:オブジェクト指向で継承は使うべきではない？
DB Magazine 10月号（古！）の『柔軟なシステムを作成するためのＣ♯によるオブジェクト指向開発の実践』という記事で、少し気になる記述があったので、ちと書いてみます。 「なお、継承は、ポリモーフィズム（多態性）を利用するときのみ使用するのが基本となっている。」 「オブジェクト指向による設計では、既存クラスを継承することはあまりない。」 ということで、たしかにJavaやC#によるプログラミングでは委譲によって実装の再利用を行うことが定石となっています。継承はポリモーフィズムのための手段でしかないのかもしれません。記事はC#に関するもので、その意味では問題視するほどの記述ではありません。ただ、これだけ言い切られてしまうと、オブジェクト指向入門的な内容とも相まって誤解する人が増えるのでは、と気になりました。 本当に「継承は悪で、委譲は正義」なのか？ これは言語の制約によるものです。ここで
Why extends is evil
Why extends is evil Improve your code by replacing concrete base classes with interfaces The extends keyword is evil; maybe not at the Charles Manson level, but bad enough that it should be shunned whenever possible. The Gang of Four Design Patterns book discusses at length replacing implementation inheritance (extends) with interface inheritance (implements). Good designers write most of their co
めもおきば - Attribute::Protected
Catalyst ドキュメント日本語版としてPODの翻訳をされている方がいらっしゃるんですね。ありがたいことです。 今のところ、5.49_01準拠なんですね。 g:hatena:id:hatenatech:20051108:1131539607の活用例にある「miyagawaモジュール」ってなんだろうと思っていたら、blog.nomadscafe.jp: Perlのattributes CGI::Application::Plugin::AutoRunmodeにてAttribute-Protectedというモジュールがあることが分かった。 やってることは、所謂OO言語にあるPublic/Protected/Privateを実現する物なんだけど、ソースを見て、あまりのエレガントさに感動。シンボルテーブルを触って、Privateを付けていたらパッケージ名が同じかどうかチェックする部分を挟んでい
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
11月08日の技術勉強会 - perlのattributes - はてな技術発表会日記 - 機能変更、お知らせなど