オブジェクト指向できていますか？3. 自己紹介 1992年～1997年 某ゲーム会社 プログラマ SFC,GB,PS1,N64のゲーム開発経験 1998年～現在 日本工学院八王子専門学校 @mozmoz1972 専任講師 プログラミング教育を中心に担当 twitterもfacebookも実名です。よかったらフォローしてください。
オブジェクト指向設計の原則がよく分かるかも知れない画像 | naglly.com
下記のサイトで、オブジェクト志向開発における原則、いわゆる「SOLID原則」について、皮肉たっぷりの画像と文章を用いて解り易く解説しています。 SOLID Development Principles - In Motivational Pictures - new ThoughtStream("Derick Bailey"); - 大変良く出来ている画像だと思いましたので、勉強の為にそれぞれの原則をネットで検索しつつ、日本語化してみました。 これは、オブジェクト指向設計の原則だけじゃなくて、ソフトウェア開発全般に適用できる原則だと思います。 The Single Responsibility Principle(SRP) The Open Closed Principle(OCP) The Liskov Substitution Principle(LSP) The Interface
システム設計日記
テスト駆動開発 和田卓人(t-wada)さんによる『テスト駆動開発』の新訳版が出版されました。 オブジェクト指向でソフトウェアを開発するのであれば、この本とマーチンファウラーの『リファクタリング』は必読書だと思います。この古典ともいえる『テスト駆動開発』が和田さんの手によって新訳版として復刊されたことは、ほんとうにすばらしいことです。 この本が出版された経緯と、和田さんはじめ関係者の方々のご努力については、和田さんの、このブログをぜひ読んでいただければと思います。 新訳版『テスト駆動開発』が出ます 新訳本は、単に原著が日本語で読めるようになっただけではありません。和田さんの手によって、原著にはない新たな価値が付け加えらました。 一つは、サンプルコードの工夫です。 できるだけ省略はしない変更箇所を目立つようにした各章末にその時点での全コードを記載する これらの工夫により、本に書かれた内容が、
各プログラミング言語のオブジェクト指向な記述方法を比較してみた ｜ blog.ks-product.com
ActionScript3.0、2.0、PHP5、JavaScript それぞれのOOPの記述方法を比較してみました。基本的に各言語のサンプルは同じ振る舞いをするので、「ASは得意だけど他の言語まで覚えるのは大変そう」と腰を重くしている人は参考になるかもしれません。 ■AS3■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■ package { public class Person { public var name:String; public var age:uint; public var sex:String; private var paramNum:uint; public function Person(__name:String=null, __age:uint=0, __sex:String=null) { paramNum = argum
FPN-ゼイヴェル・大浜史太郎社長へのインタビューを読んだ
2．ビジネスリサーチの情報収集 日常的な情報収集・整理術（Feedly＋Dropbox） 【 ビジネス 情報収集 と 情報整理 の基本 】いま目の前にあるリサーチプロジェクトとは別に、普段からデジタル時代の「新聞 切り抜き」に相当する情報収集・整理を行う必要が… 2021.02.10 2021.05.08 289 view コラム〜リサーチャーの日常 トリプル ディスプレイ モニター 在宅勤務が常態化している人は、まず トリプル ディスプレイ 環境に投資することを考えてみてください。作業効率の圧倒的向上が可能です。… 2021.05.06 2021.05.11 205 view 1．ビジネスリサーチの基本・心構え すべては「依頼」から始まる〜社内リサーチャーと社外リサーチャ… 【 リサーチャー とは 】企業で企画系の仕事をしていると、上司の依頼で調べものをして資料にまとめるという仕事が多い
オブジェクト指向について考える - yokkunsの日記
オブジェクト指向は、人によって理解が違って、それを上手く共有出来ないと凄い認識違いが起きたりするので、ここで自分の考え方をまとめてます。 ここでいうオブジェクト指向は、クラスベースのオブジェクト指向のことです。 制限と拡張 オブジェクト指向は、それまで出来ていたことに対する制限とそれまで出来なかったことという拡張の２つの側面があります。 制限 カプセル化（※1） 言語仕様として、公開範囲を決められる 拡張 ポリモーフィズム 継承やインタフェースを用いる事により、様々なテクニックが使える この２つは、全くの別の概念として説明されることが多いですが、どちらも「相手に必要な情報しか渡さない」と考える事が出来ます。 カプセル化 相手に必要ない「内部構造と実装」を隠蔽する ポリモーフィズム 相手に必要ない「必要としてる型以外の情報」を隠蔽する これを確認するために、オブジェクト指向が出来るまでの流れ
クラスが持つ3つの役割 - 西尾泰和のはてなダイアリー
某所のチャットで話題になって、流れ去りそうだったのでもったいないから転載しておいた。事後承諾で。 MIYAMOTO Daisuke: 型の継承と実装の継承を区別する方法がないんだよな。 西尾泰和(nishio.hirokazu): 型を継承させずに実装を継承させたい→それ移譲で ってことかな？ MIYAMOTO Daisuke: そそ。そもそも、クラスに「型としての役割」と「実装としての役割」という複数の責務があることに、俺は長い間気づかなかった。これに気づかないと、型継承と実装継承が頭の中で整理できない。 西尾泰和(nishio.hirokazu): 僕が最近気づいたことも加えると、クラスには「ユーザ定義型」「インスタンスを作成する道具」「実装の再利用の単位」という3つの役割がある。 MIYAMOTO Daisuke: あぁ、インスタンスの生成器ね。 西尾泰和(nishio.hiroka
依存関係逆転の原則
チェストの依存関係 私たちの身の回りにあるものは、たいてい細かいオブジェクトが大きなオブジェクトに依存しています。 たとえばチェスト。 チェストには枠と引き出しがありますね。 引き出しは、チェストの大きさによって3つくらいだったり、7つくらいだったりします。 これ、枠と引き出しの依存関係はどうなってるんでしょう？ 枠が引き出しに依存してるんでしょうか？ 引き出しが枠に依存してるんでしょうか？ 先に枠があって、それにあわせて引き出しが作られたんでしょうかね？ とすると、引き出しが枠に依存しているといえそうですね。 んー、先に引き出しがあって、それに合わせて枠を作るってのは、なんか不自然なカンジですね。 とすると、やっぱり引き出しが枠に依存してるのかな。 と、ちょっと待ってください。 この問題、そもそものスタートから間違ってます。 誰も、なんにもなしでいきなりチェストの枠を作り出したり、引き出
ダックタイピングという考え方は間違ってると思いませんか？ - http://ja.wikipedia.org/wiki/%E3%83... - Yahoo!知恵袋
ダックタイピングという考え方は間違ってると思いませんか？ http://ja.wikipedia.org/wiki/%E3%83%80%E3%83%83%E3%82%AF%E3%83%BB%E3%82%BF%E3%82%A4%E3%83%94%E3%83%B3%E3%82%B0 今のオブジェクト指向言語はダックタイピングが当たり前、Javaのinterfaceは古い、 という意見をネット上で見かけたのですが、正しいと思いますでしょうか。 かつてC言語とPerlしか知らなかった私は、Javaのinterfaceを知って衝撃を受け、 そこからポリモーフィズムなどのオブジェクト指向設計を意識するようになりました。 クラス型が違えど同じメソッドを持っていれば同様に処理する、というダックタイピングのメリットは私には理解できません。 異なるクラスで、たまたま名前とパラメータが同じでも、中身の動作が違う
クラスがメソッドの実行に必要なインスタンスを手に入れる方法色々 - 都元ダイスケ IT-PRESS
あるクラスが、メソッドによってある役割を果たすためには、別のインスタンスが必要なことが多い。ここでは、具体的にそのクラスを考え、そのインスタンスのを手に入れる方法を比較していこう。 ここでは、あるクラスをSqlExecutorとしよう。SQL文を受け取って、データベースのConnectionを使って実行するクラスだ。そして、SQL実行結果(ResultSet)をResultHandlerに渡して処理をする。さて、このクラスが責務を果たすためには「SQL文」「データベースConnection」「ハンドラ」の3つのインスタンスが必要だ。このクラスをいくつか書いて、比較してみよう。 どのインスタンスを、どのように受け取るかの違いだ。各インスタンスに対して、「setterで受け取る方法」「コンストラクタで受け取る方法」「メソッド引数で受け取る方法」がある。 A.全てsetterで受け取る方法 im
依存関係逆転の原則（DIP） - Strategic Choice
依存関係逆転の原則（DIP:the Dependency Inversion Principle）上位のモジュールは下位のモジュールに依存してはならない。どちらのモジュールも「抽象」に依存すべきである。「抽象」は実装の詳細に依存してはならない。実装の詳細が「抽象」に依存すべきである。どういうこと？手続き型は「方針」が実装の「詳細」に依存する構造になってしまう。 方針が詳細の変更に影響されてしまう好ましくない構造。 OOプログラミングでは「方針」「詳細」とも抽象に依存させることで、悪しき依存関係を逆転できる。 なんで？アプリケーションの方針を決めていて、他に対して影響を与えるモジュール(＝言うなれば「偉い」ヒト)は上位。 上位が下位に依存してしまうと、上位が、下位の影響を受けてしまう。手続き型でよく見られた悪い依存関係。 筋的にはアプリケーションの存在理由である上位が下位に対して影響力を持つ
連載：.NETで始めるデザインパターン 第7回 デザインパターンの落とし穴（2/2） - ＠IT
■保守性を考慮したパッケージ分割の指針 それでは、このパッケージ分割の指針としての6つの設計原則を紹介しよう。これらの設計原則は第2回のGRASPパターンで説明した「凝集度（Cohesion）と結合度（Coupling）」を基に分類されている。高凝集性と疎結合性に注目することがオブジェクト指向設計の要であることを再認識していただきたい。 以下に、『アジャイルソフトウェア開発の奥義』に記載されている、パッケージに関する6つの設計原則を紹介する。
guice/ServiceLocator - tech.cm55.com
Injectorをサービスロケータとして使う DIの考え方は非常にとっつきにくい。とっつきにくい原因は「制御の逆転」である。通常、我々があるクラスを作成する場合はその中で「好きな時に好きなオブジェクトを好きなだけ生成して使う」というやり方である。が、DIではそうはならない。「そのクラスで使うべきであろうオブジェクトがどこかで勝手に生成され、勝手に用意される」といった具合になる。 つまりこれは、考えるべき問題の範囲がクラスの外側にはみ出してしまうことを意味する。これまではクラスの中でだけ問題（いつどんなオブジェクトを生成するか）を考えればよかったにも関わらず、DIを使うとクラス以外の部分でそれらを検討する必要が出てくる。これは面倒だし、間違いが発生する可能性も大きい。追うべき範囲が広がるのでおそらくデバッグも難しくなる。 SpringのようにオブジェクトのセットアップをXMLを使って行うフレ
Scrabble.NET » Service Locatorとして使う
前章ではひとしきりHello-worldなUnityの使い方を説明しましたが、Unityをnewの代わりに使われたのではDIコンテナの汚名挽回というものです。 この章ではUnityをService Locatorとして使用する方法を説明します。DIはまだおあずけなのです。 サンプルコード: [Sample] – ServiceLocator 今回はインターフェイスとその実装クラスを２つ用意します。 1: public interface ISay 2: { 3: void Say(); 4: } 5: 6: /// <summary> 7: /// こんにちは 8: /// </summary> 9: public class SayHello : ISay 10: { 11: public void Say() 12: { 13: Console.WriteLine("Hello
『ドメインモデルに対する日米の温度差』
マーチン・ファウラー氏によれば、アプリケーションの中核部であるビジネスロジックを構築する方法には、Transaction ScriptパターンとDomain Modelパターンの2通りがあるという。Domain Modelパターンは、データと振る舞いを1つのオブジェクトにまとめ、オブジェクト指向のテクニックを駆使するやり方だ。一方のTransaction Scriptパターンでは、データと振る舞いは別々のオブジェクトに分け、振る舞いをスクリプト的に淡々とプログラミングしていく。 日本ではTransaction Scriptが優勢 この2通りのうち、日本ではTransaction Scriptパターンの方が優勢だ。日本のオピニオンリーダーも軒並みTransaction Scriptを薦めている。 たとえば、Seasarの開発者であるひがやすを氏は、古くからデータと振る舞いを分離するアプローチ
Martin Fowler's Bliki in Japanese - ドメインモデル貧血症
http://martinfowler.com/bliki/AnemicDomainModel.html これはずいぶん昔からあるアンチパターンのひとつですが、今になって台頭してきているようです。 Eric Evans と話したのですが、彼も、それがだんだんポピュラーになってきていることに気づいていました。 私たちほど大の「真Domain Model」推進者としてみれば、ちょっとうれしくありません。 ドメインモデル貧血症の基本的な症状は、一見、それが本物のドメインモデルに見えるという点です。オブジェクトがいくつかあり、それらはドメイン空間にある名詞から名前をつけられています。それから、オブジェクト同士がしっかりとしたリレーションで結びついており、本物のドメインモデルと同じような構造を持っているのです。 ただし、オブジェクトの振る舞いを見れば違いが分かります。それらのオブジェクトにはわずかな
アラン・ケイが考えるオブジェクト指向プログラミング - @katzchang.contexts
OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things. It can be done in Smalltalk and in LISP. There are possibly other systems in which this is possible, but I'm not aware of them. Dr. Alan Kay on the Meaning of "Object-Oriented Programming" 私が考えるOOPはメッセージング、状態処理のローカルでの保有・保護・隠蔽、そして全ての物に対する強力な遅延束縛、これだけだ。これはSmalltalkとLISP
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
IBM Developer
http://www.rvdavid.net/my-zend-framework-model-layer-part-service-part-orm/
汝の隣人のブログを愛せよ | LOVELOG