オブジェクト指向について - きしだのHatena
参考までに、ぼくの基本的な定義は、ランボーの「データ構造と振る舞いが一体となったオブジェクトの集まりとしてソフトウェアを組織化すること」という定義に従っています。そのようなオブジェクトが単体ではなく組織化されるということが重要です。オブジェクト指向を勉強するとはそのような組織化のしかたを勉強することだと考えています。 現在のシステムは、データはデータベースに格納され、振る舞いとは分離して管理されています。そのような中では、システムをオブジェクトの集まりとして組織化することはできません。 局所的にも、ステートレスを前提としたHTTPの処理では、オブジェクト組織の必要な局面はありません。 個別のオブジェクトの共通化に継承を使うという点では「クラスは単にユーザー定義型であり、継承は部分型と差分プログラミングを実現する仕組みだととらえる」だけで充分だと考えています。 そうしたシステムにオブジェクト
依存関係逆転の原則（DIP） - Strategic Choice
依存関係逆転の原則（DIP:the Dependency Inversion Principle）上位のモジュールは下位のモジュールに依存してはならない。どちらのモジュールも「抽象」に依存すべきである。「抽象」は実装の詳細に依存してはならない。実装の詳細が「抽象」に依存すべきである。どういうこと？手続き型は「方針」が実装の「詳細」に依存する構造になってしまう。 方針が詳細の変更に影響されてしまう好ましくない構造。 OOプログラミングでは「方針」「詳細」とも抽象に依存させることで、悪しき依存関係を逆転できる。 なんで？アプリケーションの方針を決めていて、他に対して影響を与えるモジュール(＝言うなれば「偉い」ヒト)は上位。 上位が下位に依存してしまうと、上位が、下位の影響を受けてしまう。手続き型でよく見られた悪い依存関係。 筋的にはアプリケーションの存在理由である上位が下位に対して影響力を持つ
インターフェイス分離の原則（ISP） - Strategic Choice
インターフェイス分離の原則（ISP:the Interface Segregation Principle） クライアントに、クライアントが利用しないメソッドへの依存を強制してはならない。どういうこと？クライアントは複数のインターフェイスを利用するけど、そのすべてが互いに強い関連を持っているわけではない。すべてのインターフェイスを１つのクラスに押し込めてしまうことはやめ、関連性持ったインターフェイスはグループ化して、抽象基本クラスとして分けて利用すべき。なんで？「太った」（多機能な）インターフェイスがある。 あるクライアントはそのインターフェイスのすべてのメソッドを利用するわけではない。 クライアントが、そのような利用しないメソッドを含むインターフェイスに依存すると、クライアントはその自分に関係のないメソッドの変更の影響をうけていしまう。 他のクライアントがクラスに強いる変更によって、それ
リスコフの置換原則（LSP） - Strategic Choice
リスコフの置換原則（LSP:the Liskov Substitution Principle）派生型はその基本型と置換可能でなければならない。どういうこと？使う側から言うと、基本型を引数にとる関数に、どんな派生型のインスタンスをもらっても気にしないで使えないとダメ。実装側から言うと、派生クラスがその基本クラスで使われるところにおいても、正常に動作することを保証しなければならない。なんで？使う側に意識させるということは、OCPに違反することになるから。つまり、LSPに違反すると、必然的にOCPにも違反してしまう。たとえば？ではまず、簡単な例。Shapeクラス、そしてその派生クラスCircle/Squareがある。Shapeにabstract関数を使わない。Circle/Squareにそれぞれ独自のDraw関数がある。ここでShapeを受け取ってDrawする関数を作ろうとすると、、、、 v
オープン・クローズドの原則（OCP） - Strategic Choice
オープン・クローズドの原則（OCP:the Open-Closed Principle）（開放−閉鎖原則） ソフトウェアの構成要素は、拡張に対して開いていて、修正に対して閉じていなければならない。どういうこと？オープン（開いている）とは？ モジュールの振る舞いを拡張できる。 クローズ（閉じている）とは？ モジュールの振る舞いを変更しても、そのソースやバイナリはまたく影響を受けない。 なんで？この原則はオブジェクト指向設計の核心。なぜなら、この原則に従えば、オブジェクト指向の最大のメリットを享受できる！ 柔軟性再利用性保守性たとえば？具体例として、よくある図形の例 。switch/caseで図形の種類ごとに処理を行う。 こうすると、図形の種類が追加になるたびにこの処理が変更になる。 ここで大事なのは、switch/caseがおそらく一箇所ではないところ。 至る所に図形の種類ごとの色々な処理が
単一責任の原則（SRP） - Strategic Choice
単一責任の原則（SRP:the Single Responsibility Principle） クラスを変更する理由は1つ以上存在してはならない。どういうこと？変更理由が2つあるということは、責任（役割）も2つあるということ。そんなジェネラリストなクラスを許さない、という原則。 ところで、「単一責任」って、クラスを作る上で一見当たり前に見える。責任（役割）をそのまま責任ではなく、変更理由としているところがポイント。 この見る角度を変えるところがこの原則の運用の大切な所。なんで？役割を複数もつクラスはもろいクラスだから。 複数の役割を担っているクラスがあって、それをある1つの理由で変更すると、関係のないその他の役割部分にまで影響を及ぼす事になり、その結果予想もしない形でクラスが壊れてしまう。 保守で違う人が修正したら簡単に壊れてしまう。 保守で変更していくと、実装的だけでなく、設計的にもよ
オブジェクト指向設計原則 - Strategic Choice
原則について優れたオブジェクト指向開発のための指針。ただ、、、原則は原則。必ず守らなければならないのではなく、まずそれで考えることが重要。逸脱したとしても正当な理由やトレードオフが説明できればよい。一覧単一責任の原則（SRP）オープン・クローズドの原則（OCP）リスコフの置換原則（LSP）依存関係逆転の原則（DIP）インターフェイス分離の原則（ISP）参考アジャイルソフトウェア開発の奥義 第2版 オブジェクト指向開発の神髄と匠の技作者: ロバート・C・マーチン, 瀬谷啓介出版社/メーカー: ソフトバンククリエイティブ発売日: 2008/07/01メディア: 大型本 Principles Of Object Oriented Designオブジェクト指向設計＠Syboos.jpオブジェクト指向設計の原則＠それはBooksオブジェクト指向設計原則＠ディノオープンラボラトリオブジェクト指向の法則
第 43 回 和田卓人 さんの巻 | オブジェクトの広場
ＯＯエンジニアの輪！ 第 43 回 和田卓人 さんの巻 今回のゲストは、和田卓人 さんです。テスト駆動開発の紹介など様々な活動で知られています。 ■ はじめに --- まこたんさんとのつながりは たぶん arton さんがまこたんを紹介した絡みに似てるかもしれないんですけど、以前「Seasar のからさわぎ」とか、 Seasar*1 のコミュニティが、よく飲み会やってたんですね。初めて会ったのもたぶんこの辺りだったと思う。 --- 2005 年ぐらいですか… ヨーロッパ選手権が 2004 年だから…… 2004 年、 2005 年ぐらいですね。 僕はサッカーが好きなんですが、サッカーファンというものは 2 年単位で年を覚えていられるんです。 4 年単位でワールドカップがあって、さらにそこから 2 年ずれて 4 年単位でヨーロッパ選手権があるので、大体あの時に何やってたってのは 2 年刻みで
オブジェクト指向をわかりたいなら今すぐ『オブジェクト指向でなぜつくるのか』を読め - 思っているよりもずっとずっと人生は短い。
オブジェクト指向の入門書と言えば『オブジェクト指向でなぜつくるのか』に決まってるよね、と話していたら、「ええ、そうなんですか？」と、この本に推薦のことばを寄せていた平鍋さんの会社の人に言われてショックでした。ちょっと駄目すぎです。角谷さんなんとかしてください（＜無茶振り）。 オブジェクト指向でなぜつくるのか―知っておきたいプログラミング、UML、設計の基礎知識― 作者: 平澤章出版社/メーカー: 日経BP社発売日: 2004/06/03メディア: 単行本購入: 34人 クリック: 448回この商品を含むブログ (198件) を見る 私もご他聞に漏れず、オブジェクト指向の本はいろいろ読んでみたのですが、『オブジェクト指向でなぜつくるのか』に勝る本は内外合わせてまだお目にかかれていません。率直に言ってプログラマ必読書だと思います。 その素晴らしさは随所にあるのですが、章立てに追って説明しましょ
静的オブジェクト指向は設計者が苦労を背負込むシステム
2009-09-26 北陸Scala第1回開催 2009-04-04 第十四回java-ja勉強会 - 第1回チキチキ 地方巡業withひがやすを飲み会in富山開催 2009-03-20 わんくま大阪勉強会#28 「ジェネリクスを使おう！」 2008-11-08 わんくま富山勉強会#1 開催 2008-08-09 わんくま東京勉強会#23 「C#登場前夜」 2008-04-01 *で始まるタイトルはエイプリルフールネタです 2008-01-26 わんくま東京勉強会#16 「ライブプログラミング」 2007-12-08 わんくま名古屋勉強会#1 「わんくま初めてのJava」 2007-07-28 開店 みねこあさんのところで挙がっていた、 静的オブジェクト指向と動的オブジェクト指向の軽さについての話題から。 Javaは経済的事情をうまく捉えて普及した プログラミングの効率と経済で書いていると
自己流オブジェクト指向＆Java参考書 『非』お勧め版 - カレーなる辛口Javaな加齢日記
お奨め本リスト*1と対をなす，非お勧め版の入門書・参考書リスト．*2 あくまで『非』お勧めの、駄本、屑本リストである点に注意。しかし皮肉な話だが，初心者を惑わす入門書を避けるためにも要チェックだろう． 主に「何故か有名だけど悪い本」を取り上げる予定．「無名だけど悪い本」はきりがないので，ここではパス．結果として持ってない本が中心になるので詳細について触れるつもりはない．*3 「オブジェクト指向本」 実は「オブジェクト指向」というのは，あまり専門的な用語ではない．*4オブジェクト指向プログラミング(OOP)，オブジェクト指向設計(OOD)，オブジェクト指向分析(OOA)などと，きちんと区別すべきだ．ただ口頭で話す時は「オブジェクト指向プログラミング」と言うのは冗長だしOOPと言っても理解してもらえない．しかたがないので省略して「オブジェクト指向」と言う時も少なくない． ここで挙げるのは「いわ
イマドキのオブジェクト指向 (arclamp.jp アークランプ)
最近、改めてオブジェクト指向の説明というものを見直すことがあったのですが、出てきた結論としては「イマドキのオブジェクト指向」という形で再編集しても良いのではないかと。 先週の丸山先生レクチャーシリーズ2007-2008 第3回「SOAの現在」で発表した「メッセージ指向によるシステム開発の変化の兆し ～遍在するメッセージ指向～」は、その表れ。ウルの河村さんと話しているときに盛り上がって、そのまま形にしたものです。 では、「イマドキのオブジェクト指向」とは何か。それはメッセージ指向という解釈です。オブジェクト指向は「メッセージによる処理の分割」であり、「分離された処理をオブジェクトと呼ぶ」と定義します。これまではオブジェクト指向とは「オブジェクトによる処理の分離」であったわけです。 背景 現在、ソフトウェアを作る時に重要なのは「処理をいかに分離し、作業を分担するのか」ということです。これはプ
いまさらながらだけど、オブジェクトとクラスの関係を究めてみようよ - 檜山正幸のキマイラ飼育記 (はてなBlog)
オブジェクトとクラスの関係について、次のような説明を見かけました（文言の引用ではなくて、檜山による要約）。 オブジェクトとクラスは全体としてツリー構造をしていて、ツリーの末端をオブジェクト、末端以外のノードをクラスという。末端であるオブジェクトは、その親ノードであるクラスのインスタンスと呼び、クラスどおしの親子関係を継承関係と呼ぶ。 うーむ、この説明、ある意味「簡潔でわかりやすい」とも言えるのだけど、ちょっと単純化し過ぎでしょ。 オブジェクトやクラスの概念て、そんなに美しくもなきゃ、整合的でもありません。実用性やら実装上の都合やらでゴチャゴチャですがね。しかし、そのゴチャゴチャが悪いともいえません。ゴチャゴチャを無理に単純化することなく、必然性を持った（幾分は偶発的だけど(苦笑)）複雑さとして理解すべきかと思います。 というわけで、メタクラスやレイフィケーション（reification）な
【レポート】Gavin King氏が語る"見えてきたWeb Beans" - JBoss COMPASS Tokyo (1) Web Beansとは? | エンタープライズ | マイコミジャーナル
Hibernateのファウンダーとして知られるGavin King氏。現在はRed HatにてJBossフェローを務める 18日、レッドハット主催による開発者向けイベント「JBoss COMPASS Tokyo」が開催された。同イベントの目玉は、HibernateやSeamといった"超メジャー"フレームワークの創設者であるGavin King氏によるテクニカルセッションである。同氏は基調講演にも登壇し、自身がスペックリードを務める「JSR 299 Web Beans」の紹介を行った。本稿では基調講演で同氏が語った情報をもとに、Web Beansの概要やメリットを簡単に説明したい。 Web Beansとは、Gavin King氏が開発を主導するアプリケーションフレームワーク「JBoss Seam」から着想を得て、現在JCP内で標準化が進められている仕様だ。Java EEの次期メジャーバージョ
[ 技術講座 ] 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）は、「
『ドメインモデルに対する日米の温度差』
マーチン・ファウラー氏によれば、アプリケーションの中核部であるビジネスロジックを構築する方法には、Transaction ScriptパターンとDomain Modelパターンの2通りがあるという。Domain Modelパターンは、データと振る舞いを1つのオブジェクトにまとめ、オブジェクト指向のテクニックを駆使するやり方だ。一方のTransaction Scriptパターンでは、データと振る舞いは別々のオブジェクトに分け、振る舞いをスクリプト的に淡々とプログラミングしていく。 日本ではTransaction Scriptが優勢 この2通りのうち、日本ではTransaction Scriptパターンの方が優勢だ。日本のオピニオンリーダーも軒並みTransaction Scriptを薦めている。 たとえば、Seasarの開発者であるひがやすを氏は、古くからデータと振る舞いを分離するアプローチ
ひがやすを blog - ドメインモデルに対する日米の温度差
ドメインモデルに対する日米の温度差 ひさびさにみたなぁ、この話題と思いつつ、コメントします。 昔書いた自分の記事をすべて読み返したわけではありませんが、どこにもトランザクションスクリプトが良いと書いたことはないはず。 この話題に関する問題の根源は、ファウラーが トランザクションスクリプトは、単純だから単純なシステムには向いている。でも、複雑な問題を扱うには、真のオブジェクト指向であるドメインモデルを使ったほうが良い。としたところにあると思います。これが、そもそもおかしい。複雑なシステムを扱うには、ドメインモデルのほうが向いているというのは根拠がない。データと振る舞いを一つにまとめることがオブジェクト指向というのも単純すぎる。 別にオブジェクト指向はこうあるべきなんていまさら議論するつもりはありませんが、私の中でのオブジェクト指向は、「それぞれのオブジェクトがきちんと割り当てられた責任を果た
自己流オブジェクト指向プログラミング＆Javaお奨め本2007年版 - カレーなる辛口Javaな転職日記
http://d.hatena.ne.jp/JavaBlack/20050909/p1の改訂．*1基本的に改訂版への差し替えと一部の新刊の追加程度になっている． お奨めのJava＆オブジェクト指向プログラミング関連の書籍／参考文献リスト．初心者向け入門書や参考書から上級者向けの専門書まで，オブジェクト指向だとかJava言語とかの初心者〜中級者が学習をすすめる上での参考にすることを想定して作っている． 初心者向け勉強の手引き：http://d.hatena.ne.jp/JavaBlack/20070825/p1 オブジェクト指向プログラミング とりあえず初心者なら「オブジェクト指向プログラミング入門」「オブジェクト指向における再利用のためのデザインパターン」と，あと「リファクタリング―プログラムの体質改善テクニック (Object Technology Series)」くらいかな．ただしリフ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
IOS/Androidアプリの３つの大事な設計方針
大抵のシステムは、ドメインモデルになっている？？ - inabatchの日記