404 Blog Not Found:オブジェクトは難しくない。難しいのはクラス
2006年11月16日16:55 カテゴリLightweight Languages オブジェクトは難しくない。難しいのはクラス 大人だからオブジェクトは難しくなる。子供にとっては実はオブジェクトは自然で自明で簡単だ。 オブジェクト指向を正しく理解する：ITpro オブジェクト指向はしばしば，とっつきづらく難しい技術と言われます。その理由の一つには，対象とする分野が広く，それぞれに深みがあることが挙げられます。しかし，それ以上にこの技術を難しくしている落とし穴とも言うべき原因が二つあると筆者は考えています。それは比喩を乱用する説明の仕方の問題と，「もの中心」を意味するコンセプト自体の問題です。事実、オブジェクト指向というのは最初は子供向けだったのだ。 このことを、現在「オブジェクトとはなんぞや」という大人たちは忘れてしまっている。 それで、オブジェクトとは何か、といえば、「自分が何が出来る
オブジェクト指向を正しく理解する - 特集 オブジェクト指向は難しくない！：selfup
オブジェクト指向はしばしば，とっつきづらく難しい技術と言われます。その理由の一つには，対象とする分野が広く，それぞれに深みがあることが挙げられます。しかし，それ以上にこの技術を難しくしている落とし穴とも言うべき原因が二つあると筆者は考えています。それは比喩を乱用する説明の仕方の問題と，「もの中心」を意味するコンセプト自体の問題です。 そこで本特集では，「オブジェクト指向という言葉をよく聞くけど，実際どんなものかよくわからない」という方のために，初心者/入門者が陥りやすい落とし穴を明確にしながら，オブジェクト指向の全体像を説明します。余計な先入観やまぎらわしいたとえ話に惑わされなければ，オブジェクト指向そのものはそれほど難しい技術ではないことを理解していただきたいと思います。なお，オブジェクト指向プログラミング，デザインパターン，分析/設計といった個々の技術については特集2以降でそれぞれ解説
脱オブジェクト指向のススメ：ビジネスをデザインするブログ：オルタナティブ・ブログ
知り合いから相談に乗ってやってくれと頼まれたので、ある若手プログラマと会って話をした。お題はスキルパスについでだ。大学を卒業後、独学でプログラミングを学び、現在は中規模開発会社で、主に業務システムの開発に携わっているそうだ。 で、相談の内容は、「このまま現在の業務を続けるか、辞めて、専門学校などでゼロからプログラミング（というかシステム構築）を学びなおすべきか」というものだった。 で、「どうして？」って聞いたところ。 「やっぱり、オブジェクト指向とか、きちんと理解していないので、基礎からやり直したいんです」とのこと。 で、よくよく話を聞いてみると、要は、現場の開発において発生するいろいろな課題を解決できないのは、オブジェクト指向などをよく理解していないからでは？と思いこんでいるようである。 「・・・・」 この手の相談を受けるたび、正直私は気が遠くなるのだ。ITmediaの紙面上で書くのは少
オブジェクト指向は構造化の「次」か? : 404 Blog Not Found
2006年01月27日16:54 カテゴリLightweight Languages オブジェクト指向は構造化の「次」か? Matzさんがこう言うのは以外な気がする。 Object Oriented Perl Damian Conway Matzにっき(2006-01-20)実際には、オブジェクト指向プログラミングは、構造化プログラミングの「次」と 認識されるべきものだと思う(OOAやOODのことは知らんけど)。 というのも、「オブジェクト指向」は「構造化」の進化系ではなく、元来直交して扱える概念だからだ。 実際smalltalkやhypertalk、そしてsqueakといったプログラミング環境では、オブジェクトはフィールドとかボタンとかといった、「もろに目に見える」「実存」であり、それ故まだものごとを抽象化して捉えることの出来ない子供でも始められるようになっている。 実はすでに適切に設計
「オブジェクト指向神話」神話 - Matzにっき(2006-01-20)
<< 2006/01/ 1 1. [教会] 元旦 2 1. 出産 2. 帰省 3. 到着 3 1. デジタル体重計のユーザインタフェース 4 1. [OOP] Classbox 2. [OOP] Classboxの実装 5 1. 帰宅 2. PCレスライフ 6 1. PC修理 7 1. 雪かき 2. [言語] プログラミング言語SRU 8 1. [教会] 断食安息日 2. あーめん 3. 筋肉痛・体調不良 9 1. 米子 10 1. [原稿] オープンソースマガジン3月号 11 1. [原稿] 日経Linux 3月号 12 1. [Ruby] Charming Ruby Compiler 2. [Ruby] The Open Nature Of Ruby 13 1. ニート娘に悩む親 2. Python Status Update 3. 泥縄 14 1. 宣教師のお手伝い 2. Simpl
web.paulownia.jp - ロールオーバーのオブジェクト指向的実装
Java等のオブジェクト指向はクラスベースのオブジェクト指向と呼ばれる。一方、JavaScriptはプロトタイプベース、あるいはインスタンスベースオブジェクト指向と呼ばれる。 クラスベースは、まずクラスを定義し、クラスを型とするインスタンスを作成することでプログラミングする。プロトタイプベースによるオブジェクト指向では、クラスの定義は必須ではなく場合によってはクラスという概念自体が存在しない。既存のオブジェクトのクローンとして新しいオブジェクトを作成し、そのオブジェクトに独自の性質を付加してプログラミングする。 JavaScriptのオブジェクトの性質は動的に変更可能。Java等では一度決定したオブジェクトの振る舞いは変更できないが、JavaScriptでは実行中の任意の場所でメソッドの動作を変更したり、新しく追加したり、削除したりすることができる。
オブジェクト指向プログラムのためのパターン言語の使用
以下の文章は、Kent Beck、Ward Cunninghamによる「Using Pattern Languages for Object-Oriented Programs」の日本語訳である。 Ward Cunningham氏の許可を得て、ここに掲載する。 Kent Beck, Apple Computer, Inc. Ward Cunningham, Tektronix, Inc. Technical Report No. CR-87-43 September 17, 1987 Submitted to the OOPSLA-87 workshop on the Specification and Design for Object-Oriented Programming. 概要 オブジェクト指向プログラミングへのパターン言語の適合について概説する。ウィンドウ・ベースの
満足せる豚。眠たげなポチ。:オブジェクト指向で継承は使うべきではない？
DB Magazine 10月号（古！）の『柔軟なシステムを作成するためのＣ♯によるオブジェクト指向開発の実践』という記事で、少し気になる記述があったので、ちと書いてみます。 「なお、継承は、ポリモーフィズム（多態性）を利用するときのみ使用するのが基本となっている。」 「オブジェクト指向による設計では、既存クラスを継承することはあまりない。」 ということで、たしかにJavaやC#によるプログラミングでは委譲によって実装の再利用を行うことが定石となっています。継承はポリモーフィズムのための手段でしかないのかもしれません。記事はC#に関するもので、その意味では問題視するほどの記述ではありません。ただ、これだけ言い切られてしまうと、オブジェクト指向入門的な内容とも相まって誤解する人が増えるのでは、と気になりました。 本当に「継承は悪で、委譲は正義」なのか？ これは言語の制約によるものです。ここで
矢沢久雄の早わかりGoFデザインパターン(1) | 日経 xTECH（クロステック）
今回は、パターンを1つだけ紹介します。「Mediatorパターン」です。GoF本では、それぞれのパターンの「目的]「背景」「効果」などが明示されています。私も、ちょっと真似をしてみましょう。複数のオブジェクトを組み合わせてプログラムの機能を実現するという目的において、オブジェクト間の関連がゴチャゴチャになってしまうという背景（問題）があり、Mediatorパターンの採用によって関連をキレイに整理できるという効果があります。説明だけでは、何のことだかわからないと思いますので、具体例をお見せしましょう。 図1[拡大表示](1)をご覧ください。これは、UML（Unified Modeling Language、ユーエムエル）と呼ばれる表記法で記述されたプログラムの設計図です。UMLでは、四角形の中に下線付きで名前を書いてオブジェクトを表し、関連のあるオブジェクトを矢印で結んで示します。ここで関連
Rubyから何を学べるか？ - L'eclat des jours(2005-12-04)
_ Rubyから何を学べるか？ 機械猫さんがRubyから学んだことというエントリーを書かれている。それは オブジェクト指向の視点の変化 本質に集中する の2点だそうだ。 このうち2番目の点については僕はそれほど同意できないのだけれど（感覚的な問題だと思うから、理由は別にない。ただDRYにどれだけ共感できるか、あるいはコミットできるかという点がそう感じる分かれ目なのかな、というようには思う。早い話、僕は必ずしもDRYではない。そのあたりが理由なのかも知れないが、僕はJavaで前準備みたいなことを記述していてもそれを本質的ではないと感じないからだ）、1番目の点についてはそう思う理由は異なるのに、同じように感じているので興味を惹かれた。 つまり、この結論の部分だ。 例えば、あるプログラムに対して機能追加をしようとする際にはJavaならば 「このデータをどう処理するクラスを定義すればよいか？」 と
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
C++で読むデザインパターン(Design Patterns read by C++)
C/C++ リファレンス
cmagazine.jp | Just another WordPress site
サービス終了のお知らせ
MicrosoftVisualC++(きっと6.0)でプログラム開発を始める予定です。…