オブジェクト指向できていますか？3. 自己紹介 1992年～1997年 某ゲーム会社 プログラマ SFC,GB,PS1,N64のゲーム開発経験 1998年～現在 日本工学院八王子専門学校 @mozmoz1972 専任講師 プログラミング教育を中心に担当 twitterもfacebookも実名です。よかったらフォローしてください。
オブジェクト指向設計の原則 - それはBooks
「アジャイルソフトウェア開発の奥義」を読んで第二弾。オブジェクト指向設計の原則に関するメモです。自分で読んで思い出せるくらいの内容しかメモってないと思われるので、もっと詳しい解説が欲しければ本書を買ってください。 本書には、クラス設計の原則として5つの原則が載っています。 単一責任の原則 (The Single Responsibility Principle: SRP) オープン・クローズドの原則 (The Open-ClosedPrinciple: OCP) Liskovの置換原則 (The Liskov Substitution Principle: LSP) 依存関係逆転の原則 (The Dependency Inversion Principle: DIP) インターフェース分離の原則 (The Interface Segregation Principle: ISP) パッケー
オブジェクト指向設計帖 巻之二
一、はじめに 今日のソフトウェアで扱う問題は非常に複雑であり、近年では、さらに複雑化かつ多様化する方向にあります。しかし困ったことに、われわれ生身の人間は、一度に考える範囲が限られている為、全ての問題を一度に取り掛かることは、現実問題として不可能です。そのため設計では、実現手段を考える上で、複雑な問題を分割する作業も必要になります。オブジェクト指向設計では、問題を構成する責務を意識して、クラスとして分割します。そして、そのクラスのインスタンスであるオブジェクトが協調作業することによって、提示された問題を解決するのです。 ここで、クラスをどうやって導出する、あるいは既存のクラスに何を実行させるか、ということを考える際に「責務(Responsibility)」という視点が非常に重要になってきます。もちろん、責務だけを考えればで優れた設計ができるわけではありません。しかしながら、責務を意識するこ
アジャイルソフトウェア開発の奥義 ロバート・C・マーチン ソフトバンクパブリッシング (感想その1 YAGNI?) 【▲→川俣晶の縁側→過去形 本の虫→感想編】
時間がないので、少しずつ読んでますが。 とりあえず第2章はほとんど飛ばしました。XPの初歩的な話は、ちょっと退屈でありすぎたので。(どこかで読んだような記憶のある話もあるし) で、以下の場所ではたと止まりました。 p116より アジャイル開発の場合、データを紙テープリーダから読み込むように上司から要求されたら、今後同じようなことが起きた場合に対応できるように変更していたはずだ。 複数のデバイスからの入力をよりシンプルに扱うために抽象クラスを導入したりするのは理解できることで、結果的により多くのデバイスの追加がやりやすくなることはあるでしょう。そこは分かるのですが。問題は、この文章が抽象クラスを導入する理由として、「現在時点でのシンプルさ」ではなく、「今後同じようなことが起きた場合に」と書いていることです。未来に起こるかもしれないことに今から備えることは、XP的にはYAGNIとして行うべきで
オブジェクト指向設計原則(Principles Of Object Oriented Design) - A Memorandum
オブジェクト指向設計原則(Principles Of Object Oriented Design)は、Robert Cecil Martin, Bertrand Meyer, Barbara Liskovを含む様々な人達により提唱された内容を Robert Cecil Martin が纏めたもの。オブジェクト指向を用いて設計を行う際に有用となる概念集 以下でRobert C. Martinによる解説を読むことができる http://c2.com/cgi/wiki?PrinciplesOfObjectOrientedDesign クラス設計に関する原則 SOLID です The Single Responsibility Principle(SRP) 責務単一原則 - A Memorandum The Open-Closed Principle (OCP) 開放閉鎖原則 - A Memor
Principles of Object-Oriented Design
1. ボブおじさんから学んだ オブジェクト指向設計の原則 RejectTalks 2007 Edition Entry [accept] [reject] (株)永和システムマネジメント RejectTalks Lightning Talks 伊藤 浩一 http://www.edit.ne.jp/~koic/ 2. 大事なことは最初に • 開発の現場 vol.11（2008年1月発売）に 『保守プロジェクトとデベロッパーテスティング』 という記事を寄稿しました – 『Web 2.0ビギナーズバイブル』をあわせてお買い 求めください • 今日はオブジェクト指向設計の原則という これらの記事に書いていないお話しをします
オブジェクト指向の法則集
1999/07/07 更新 石井 勝 はじめに ここでは，オブジェクト指向に出てくる法則・原則をまとめました．パターンに比べてほとんど知られていないのが現状ですが，優れたオブジェクト指向開発者を目指すならデザインパターンよりまずこっちを理解し覚えてしまいましょう． これらの法則は，絶対守らなければならないというものではありません．開発中に法則が守られているか意識することが重要です．つまり 今行っている設計はその法則が守られているだろうか その法則を破っている場合，破るべき正当な理由があるだろうか と絶えず考えるようにしましょう．そうするとそれは自然に優れたオブジェクト指向設計になるのです．つまりこれらの法則は，優れたオブジェクト指向開発のための指針なのです． Robert C. Martin の Principles of OOD Robert C. Martinは，オブジ
まさーるのページ
石井 勝 masarl@nifty.com まさーるのページにようこそ！ このサイトでは，オブジェクト指向やプログラミングの話題を扱っています．書いていることはXPやデザインパターンなどですが，最終的には，どうすればSEが行っている作業を面白くし，仕事を楽にできるか，ということを目指しています．それでは，どうぞ． [プロフィール] [リンク集] [編集後記] [Cotton Bolls] What's New NUnit Converter ver 1.0.0 ― 2004/07/04 Contents Eclipse Quick JUnitプラグイン (2003/12/23) Eclipse上でJUnitの起動，テストコードと実装コード間のエディタ切り替えを簡単に行うためのプラグインです． JUnit Diffプラグイン (2003/12/23) JUni
匠Style | Drop | ホームページ
オブジェクト指向方法論Drop Developer's Rules of the Object-Oriented Process Version 2.0 Beta 2.4 by Junzo Hagimoto 1995年から作成したちょっと古めの開発方法論ですが、オブジェクト指向技術を最大限に活かした方法論です。 みなさんの参考になればと思いここに公開いたします。 公開中の内容・構成については、変更されることもあります。現在のDrop 2.0Betaの作成状況を下記のマークで示しています。 完成かな？ もう少しです まだまだ 現在も相変わらず修正中です。 なお、Dropの内容をよりよくするために、みなさんのご質問、ご意見をお待ちしております。また、みなさんからのご意見は、以下のDrop Q&Aにてご紹介させていただきます。 Q&A history discussion download
Value Object の設計 - Aufheben - GLAD!! の日記
まずは、設計・実装における Value Object を整理した方が良さそうなのでまとめてみました。 Value Object の設計方法としては、以下の3通りがあると認識しています。 # 仕事で主に使用してきた言語が C++ と Java なので、もし他にもあればご教示ください。 1. Singleton インスタンスを1つしか生成しないパターンです。 Java の enum がこれに該当します。 同一性は == で判定することができます。 2. 不変オブジェクト インスタンスが1度生成されたら、属性の変更を許可しないパターンです。 Java のプリミティブ型のラッパークラス(Integer など)、String、BigDecimal などが該当します。 Java の場合、hash と equals メソッドをオーバライドする必要があります。 3. スコープ外へ公開する際に複製する クラ
オブジェクト指向をわかりたいなら今すぐ『オブジェクト指向でなぜつくるのか』を読め - 思っているよりもずっとずっと人生は短い。
オブジェクト指向の入門書と言えば『オブジェクト指向でなぜつくるのか』に決まってるよね、と話していたら、「ええ、そうなんですか？」と、この本に推薦のことばを寄せていた平鍋さんの会社の人に言われてショックでした。ちょっと駄目すぎです。角谷さんなんとかしてください（＜無茶振り）。 オブジェクト指向でなぜつくるのか―知っておきたいプログラミング、UML、設計の基礎知識― 作者: 平澤章出版社/メーカー: 日経BP社発売日: 2004/06/03メディア: 単行本購入: 34人 クリック: 448回この商品を含むブログ (198件) を見る 私もご他聞に漏れず、オブジェクト指向の本はいろいろ読んでみたのですが、『オブジェクト指向でなぜつくるのか』に勝る本は内外合わせてまだお目にかかれていません。率直に言ってプログラマ必読書だと思います。 その素晴らしさは随所にあるのですが、章立てに追って説明しましょ
いまさらながらだけど、オブジェクトとクラスの関係を究めてみようよ - 檜山正幸のキマイラ飼育記 (はてなBlog)
オブジェクトとクラスの関係について、次のような説明を見かけました（文言の引用ではなくて、檜山による要約）。 オブジェクトとクラスは全体としてツリー構造をしていて、ツリーの末端をオブジェクト、末端以外のノードをクラスという。末端であるオブジェクトは、その親ノードであるクラスのインスタンスと呼び、クラスどおしの親子関係を継承関係と呼ぶ。 うーむ、この説明、ある意味「簡潔でわかりやすい」とも言えるのだけど、ちょっと単純化し過ぎでしょ。 オブジェクトやクラスの概念て、そんなに美しくもなきゃ、整合的でもありません。実用性やら実装上の都合やらでゴチャゴチャですがね。しかし、そのゴチャゴチャが悪いともいえません。ゴチャゴチャを無理に単純化することなく、必然性を持った（幾分は偶発的だけど(苦笑)）複雑さとして理解すべきかと思います。 というわけで、メタクラスやレイフィケーション（reification）な
『[お知らせ] オブジェクト倶楽部クリスマスイベント参加』
オブジェクト倶楽部クリスマスイベント2007（12/21）にて、オブジェクトの広場名義で発表の機会をいただいた。「オブジェクト指向の過去・現在・未来」というテーマで、過去編を広場メンバのyojikさん、未来編を同じく広場メンバの大村君（a.k.a. everpeace）、そして現在編を私が担当した。 OO厨厨トレイン（オブジェクトの広場） 私が発表に加わったのがこれ。オブジェクト指向の現在ということで、半ば恣意的に次の3つを現在の切り口として紹介させていただいた。- DI ＋ AOP - サービス指向アーキテクチャ（SOA） - ドメイン駆動設計（DDD） そのうちのDDDについては、DDDパターンの全体像を何とか1枚のスライドで視覚的に説明したいと思い、苦労して作った図がある。かなり頑張って作ったので、ここでも再掲したい。 この1枚の図を元にDDDの全体像を細かく語りたかったのだが、時間
オブジェクト指向の概念の発明者は誰ですか？ - Smalltalkのtは小文字です
忙しい人のためのまとめ 一般に「オブジェクト指向プログラミング」と呼ばれる考え方には発案者が異なる二系統がある。（ただし簡単のため、次のうち前者から批判的に派生して生じたプロトタイプベースのオブジェクト指向はここには含めていない） アラン・ケイによる、変化に強い長期運用可能な遅延結合システムを SIMULA67 にあった「オブジェクト」をメッセージの受け手とすることで実現（オブジェクトにメッセージ送信）するアイデアに基づく「メッセージングのオブジェクト指向」と、 ビアルネ・ストラウストラップ（前後して抽象データ型を発案したリスコフ本人、オブジェクトクラスを考えたニガードらSIMULA陣営、Eiffelのメイヤーらも同様の着想を得ている）による、ユーザー定義型（抽象データ型）を SIMULA67 にあった「クラス」という言語機能を使って実現（カプセル化、継承、多態性）するアイデアに基づく「抽
『ドメインモデルに対する日米の温度差』
マーチン・ファウラー氏によれば、アプリケーションの中核部であるビジネスロジックを構築する方法には、Transaction ScriptパターンとDomain Modelパターンの2通りがあるという。Domain Modelパターンは、データと振る舞いを1つのオブジェクトにまとめ、オブジェクト指向のテクニックを駆使するやり方だ。一方のTransaction Scriptパターンでは、データと振る舞いは別々のオブジェクトに分け、振る舞いをスクリプト的に淡々とプログラミングしていく。 日本ではTransaction Scriptが優勢 この2通りのうち、日本ではTransaction Scriptパターンの方が優勢だ。日本のオピニオンリーダーも軒並みTransaction Scriptを薦めている。 たとえば、Seasarの開発者であるひがやすを氏は、古くからデータと振る舞いを分離するアプローチ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
