オブジェクト指向できていますか？3. 自己紹介 1992年～1997年 某ゲーム会社 プログラマ SFC,GB,PS1,N64のゲーム開発経験 1998年～現在 日本工学院八王子専門学校 @mozmoz1972 専任講師 プログラミング教育を中心に担当 twitterもfacebookも実名です。よかったらフォローしてください。
ArticleS.UncleBob.PrinciplesOfOod
What is object oriented design? What is it all about? What are it's benefits? What are it's costs? It may seem silly to ask these questions in a day and age when virtually every software developer is using an object oriented language of some kind. Yet the question is important because, it seems to me, that most of us use those languages without knowing why, and without knowing how to get the the m
A Monotonic Superclass Linearization for Dylan
Abstract Object-oriented languages with multiple inheritance and automatic conflict resolution typically use a linearization of superclasses to determine which version of a property to inherit when several superclasses provide definitions. Recent work has defined several desirable characteristics for linearizations, the most important being monotonicity, which prohibits inherited properties from s
いまさらながらだけど、オブジェクトとクラスの関係を究めてみようよ - 檜山正幸のキマイラ飼育記 (はてなBlog)
オブジェクトとクラスの関係について、次のような説明を見かけました（文言の引用ではなくて、檜山による要約）。 オブジェクトとクラスは全体としてツリー構造をしていて、ツリーの末端をオブジェクト、末端以外のノードをクラスという。末端であるオブジェクトは、その親ノードであるクラスのインスタンスと呼び、クラスどおしの親子関係を継承関係と呼ぶ。 うーむ、この説明、ある意味「簡潔でわかりやすい」とも言えるのだけど、ちょっと単純化し過ぎでしょ。 オブジェクトやクラスの概念て、そんなに美しくもなきゃ、整合的でもありません。実用性やら実装上の都合やらでゴチャゴチャですがね。しかし、そのゴチャゴチャが悪いともいえません。ゴチャゴチャを無理に単純化することなく、必然性を持った（幾分は偶発的だけど(苦笑)）複雑さとして理解すべきかと思います。 というわけで、メタクラスやレイフィケーション（reification）な
Introduction to Object-Oriented System Analysis and Design
第1章 狭義のオブジェクト指向 まず，オブジェクト指向をプログラミングの観点にしぼって解説を試みよう。はじめに約束したように，プログラムのコードや数式などをいっさい利用しないで解説する。オブジェクト指向の考え方の基本である抽象データ型，インヘリタンス，ポリモルフィズムの図的な解説を通して，オブジェクト指向のミクロコスモス(小宇宙)を把握していただければと思う。 1.1 なぜオブジェクト指向か オブジェクト指向の考え方の源はSimulaというプログラミング言語にさかのぼる。Simulaは1960年代後半にノルウェーで生まれたシミュレーションのための言語であり[1]，現在のオブジェクト指向の基本的な考え方を兼ね備えていた。この考え方は，Xeroxパロアルト研究所で開発されたSmalltalkという言語に受け継がれ[2][3]，LispやCなどにも影響を及ぼし，現在に至っている。したがって，25
webで読む。オブジェクト指向システム分析設計入門
はじめに この本はオブジェクト指向技術を利用してソフトウェア開発することを目指す技術者および管理者のために書かれた本です。プログラムのコードや難しい数式などを排除してあり，図と文章によって基本概念や適用技術を平易に解説しています。オブジェクト指向技術を数学(形式)ぬきで探求する試みといえるでしょう。 本来，オブジェクト指向技術を，瓶から瓶へ水をもらさぬように，正確に伝えるには，数学(型理論)を必要とします。数学的形式化が行われていないと，オブジェクト指向で表面化する問題の議論がかみ合わず空転することが多いからです。あの時はこうだっだ，この時にはああだったと経験則の披露になりかねないのです。やはり何かしらの形式化は必要でしょう。しかし，数学的形式化の苦しみときたら並大抵ではありません。特に，後述するインヘリタンス(継承) や並列などが絡んだあかつきには残酷なのです。私だけかもしれません
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
業務系のクラスでインタフェイスの実装クラス名に「インタフェイス名+Impl」って名前をつけるのはダサいよね。 - wildcatsの日記
実装に特性があるからインタフェイスと実装を分離するわけで*1 インタフェイスに対して実装が1クラスになる場合にはインタフェイスと実装を分離する必要が無いとボクは思うね。 追記：特定のDIコンテナの話はこのエントリと無関係です。 追追記：他所での議論の延長でボクの考えをここに書いただけなので、特定のDIコンテナとか特定の設計手法とかは何も関係ない（というか意識もしていなかった）話ですけど。 上にも例外として書いたしコメントにも書いたんだけど、たとえばトランザクション自動制御とかでFacadeに対してAspectをかけたい場合の設計手法の一つとしてインタフェイスと実装を強制的に分離（インタフェイスと実装が1対1)してDynamic Proxyを使う設計手法を用いても構わないのではないでしょうか？最近のプロジェクトでDIコンテナは使ってないけどHibernateのセッションとかの管理をFacad
オブジェクト指向プログラムのためのパターン言語の使用
以下の文章は、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. 概要 オブジェクト指向プログラミングへのパターン言語の適合について概説する。ウィンドウ・ベースの
JavaScriptっぽい。 JavaScript OOPなリンク集
とりあえず自分で書いたのも含めて、後でゆっくり読みたいものなどを片っ端からリンク。選出基準は適当です。 JavaScriptっぽい。 prototype覚書 GAC なぜなにGAC->フォーラム->【JavaScript】 Functionで遊ぼう [教えて！goo] クラスの継承の仕方 オブジェクト（Object）（とほほ） JavaScript, Neo-Generation/Function 自作オブジェクトで複数のメソッドを呼び出したい Virgo - JavaScript - ユーザ定義オブジェクト ECMAScriptチュートリアル ECMAScript - on Surface of the Depth - Effective JavaScript - Dynamic Scripting オブジェクトなJSの基礎講座 プロトタイプチェインについての覚書（ECMAScript,
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Why Copying an Object is a terrible thing to do?
Introduction to Object-Oriented System Analysis and Design
Why interfaces are poor contracts
柔軟性、構造安定性のデザイン: 非同期メッセージモデル、OOPとFunctional Programming
オブジェクト指向プログラミング：より良いデザインのために動詞・名詞のメタファーを超えて考える
https://www.cs.utexas.edu/users/wcook/papers/OOPvsADT/CookOOPvsADT90.pdf