オブジェクト指向プログラミングを神格化するような記事が流れてきたので，僕が知っている問題点について書いてみたいと思います．僕がまだ学生だったころは，オブジェクト指向の評価もまだそれほど定まっていなくて，オブジェクト指向の次はどんなパラダイムが出てくるかとか普通に学生レベルで議論していたものですが，ここまで強大になってしまうとそれを打ち負かそうなんて気にはならないのでしょうか．僕にはオブジェクト指向が普遍的な真理という感じは全然しなくて，ここまで使われてる理由は，現実的なテクノロジーで大きなシステムを作らなければならない必要性のほうを優先した結果であると認識しています．オブジェクト指向がその後の25年ほどもずっと安定してその地位を保てるほど素晴らしいものとは思えないのです． 以下で上げる問題点は，個別に解決している研究はあったりしますし，僕も論文を書いたりしましたけど，実際の言語に導入されて
一、はじめに 今日のソフトウェアで扱う問題は非常に複雑であり、近年では、さらに複雑化かつ多様化する方向にあります。しかし困ったことに、われわれ生身の人間は、一度に考える範囲が限られている為、全ての問題を一度に取り掛かることは、現実問題として不可能です。そのため設計では、実現手段を考える上で、複雑な問題を分割する作業も必要になります。オブジェクト指向設計では、問題を構成する責務を意識して、クラスとして分割します。そして、そのクラスのインスタンスであるオブジェクトが協調作業することによって、提示された問題を解決するのです。 ここで、クラスをどうやって導出する、あるいは既存のクラスに何を実行させるか、ということを考える際に「責務(Responsibility)」という視点が非常に重要になってきます。もちろん、責務だけを考えればで優れた設計ができるわけではありません。しかしながら、責務を意識するこ
ソリューション開発部の田中です。 ここに書いたのは、私が設計・実装したJavaのフレームワーク開発を主に通じて理解したオブジェクト指向の原理原則です。 私は単なるエンジニアであって学者や研究者ではない上に、オブジェクト指向について誰かから教わった経験も無いため、ここに書いてある内容は科学的に吟味されたものではありません。 しかし、普段の仕事の中で気付いた合理性のある内容だと考えています。オブジェクト指向言語を日常使ってはいても、オブジェクト指向そのものをみっちりと学習したことがない人にとって特に役立つ内容だと思います。 前回の記事はこちら。 役割ではなく、それを実行するための状態を考えるクラスを定義する際にはユーザからの業務要件が基になりますが、それはシステムあるいはプログラム、つまりオブジェクト指向で言えばクラスの役割を規定しているだけです。役割を規定しただけではモノを決められないことは
ソリューション開発部の田中です。 ここに書いたのは、私が設計・実装したJavaのフレームワーク開発を主に通じて理解したオブジェクト指向の原理原則です。 私は単なるエンジニアであって学者や研究者ではない上に、オブジェクト指向について誰かから教わった経験も無いため、ここに書いてある内容は科学的に吟味されたものではありません。 しかし、普段の仕事の中で気付いた合理性のある内容だと考えています。オブジェクト指向言語を日常使ってはいても、オブジェクト指向そのものをみっちりと学習したことがない人にとって特に役立つ内容だと思います。 前回の記事はこちら。 責務でクラスは決まらない「責務」によってクラスが定義されるといくつかの解説書には書いてありますが、これは誤りだと私は考えています。誤りが言い過ぎだとしても、大きな誤解を与えています。 責務という言葉を言い換えると しなければならないこと出来なければなら
1. はじめに 皆さん、こんにちは。私はオージス総研でオブジェクト指向技術を用いたSI、コンサルティングを業務とする、プロの仕事を目指す、一介のUMLシルバーレベル1のプログラマ2です。ソフトウェア業界では、オブジェクト指向も、もはや普通の技術として認知されています。有名なマイクロソフトのVB、VC++をはじめ、現在使用している開発環境のほとんどは、すべてオブジェクト指向をサポートしているといってもよいでしょう。オブジェクト指向を知らない人でも、気が付かないうちにオブジェクト指向している、なんてこともあるようです。 でもオブジェクト指向は、単にソフトウェアをより良く作るための手段のひとつですから、上手く利用しないと、そうするつもりはなくても、とんでもないソフトウェアを作ってしまうことになりかねません。悲しいことに、オブジェクト指向は結構敷居が高いと思います。オブジェクト指向のメリットである
前置き： 特定の言語ではなく、関数型言語一般に関する説明です。 ここに書くのが良いのかわかりませんが、それを考える時間ももったいないのでとりあえず書きます。必要が生じたら移転します。 皆様のご要望や自分の気分(?)により随時加筆修正します。 「それは違うんじゃない？」というご指摘はもちろん、初心者の方の素朴な疑問・質問や、「ここがよくわからない」「こういうことも書いてほしい」みたいなコメントも歓迎します。すぐに対応できない場合もあると思いますがすみません。Twitterのesumii宛でも構いませんが、コメントのほうが他の方も見つけやすくて良いと思います。当然ながら（他者に対しても）誹謗中傷等はご遠慮ください。 いただいたコメントはほぼ本文に反映していますので、本文を読むために、必ずしもコメントを読む必要はありません。もちろん、興味と余裕(?)があればコメントも読んでいただければ非常に有用
〔PHPカンファレンス2013 発表資料〕PHPとJavaScriptはどちらもオブジェクト指向言語ですが、PHPはクラスベース、JavaScriptはプロトタイプベースという違いがあります。本発表では、クラスベースとプロトタイプベースがどのように違うのかを、仕組みから詳しく解説します。またプロトタイプベース特有のパターンについても説明します。 対象：初級〜中級Read less
［書籍紹介］ 6．オブジェクト指向による設計 ここでは、オブジェクト指向による設計方法のよきガイドとして、パターンについて書かれた本を2冊紹介します。パターンとは、特定の問題に対する優れた設計方法を特定のフォーマットで記述し、その考え方や具体的な解決を多くの人たちで共有し合おうという目的でまとめられたもので、いわゆるソフトウェア開発のための定石集に該当します。 オブジェクト指向の設計とは、つまるところ、どんなクラスをどうやって組み合わせるかに尽きるので、設計のノウハウについては、なんだかんだと蘊蓄をたれるよりも、実際の組み合わせを見たほうが全然早いのです。どうもパターンというと何となく難しいものという認識があるようですが、発想自体は決してそんなに難しいことではありません。 そんなわけで、設計に関してお勧めする本は、パターンを扱った次の2冊になりました。最初の本で扱っているデザインパターンは
1 はじめに SmalltalkのOJTを通して、「Smalltalkへのスムーズな導入」を行うために、いくつかの留意点があることを私は学びました。 ① データとアルゴリズムがパックされたオブジェクト(情報隠蔽) ② オブジェクト間コニュニケーション(メッセージ伝送) ③ クラスとインスタンス関係(メタクラスとクラス関係) ④ クラス階層構造(インヘリタンス機能) ⑤ アルゴリズムをデータとして扱うこと(closure/continuation) ⑥ Model-View-Controller(MVC) ⑦ 依存性(change&update) ⑧ プラガブルの考え方(pluggableMVC) ①〜④までは、オブジェクト指向プログラミングという形で多くの解説書が手に入りますので問題はありません。 ⑤は、LispやPrologを知っておられる方には簡単になじめます。アルゴリズムをデータとし
(PgDay2012発表資料) SQLにとって、なぜO/Rマッパーが重要かを説明した資料です。Read less
Not your computer? Use a private browsing window to sign in. Learn more about using Guest mode
You probably know that Rubinius is a Ruby whose implementation is mostly written in Ruby. While that sounds nice in theory, you may not know what that means in practice. Over the past several years, I've contributed on and off to Rubinius, and feel that as Rubinius has matured since the 1.0 release, a lot of its promise has gelled. One of the great things about Rubinius is that it exposes, as firs
リアクティブプログラミングは、「時間とともに変化する値」＝「振る舞い」同士の関係性を記述することでプログラミングを行うパラダイムです。 GUIなどのようにインタラクティブなシステムや、シミュレーションやアニメーションのようにダイナミックに状態が変化するようなシステムを宣言的に記述することができます。 これらの「変化する状態」や「外部とのやりとり」が支配的なシステムは、純粋関数型言語が、その強みを発揮しにくい部分でもあります。 本稿では、リアクティブプログラミングが副作用を含む系を宣言的に記述することを可能にし、状態の管理という厄介な問題からプログラマを開放する可能性があることを示したいと思います。 （割と独自研究に基づく解釈ばかりなのでその点ご了承ください。あと例としてでてくるコードは、Pythonベースの擬似コードで具体的なライブラリに基づくものではありません。） Why Reactiv
ハッカーと画家(ポール・グラハム)という名著の力強いLISPのエールにより，今後，LISPがリバイバル的に大ブレークする予感がある。 現に，最近LISPの名著と言われるものが，中古ですら，ますます手に入りにくくなったのは，ポール・グラハムのせいではないかと思われる。 (2007/02/14)
1999/07/07 更新 石井 勝 はじめに ここでは，オブジェクト指向に出てくる法則・原則をまとめました．パターンに比べてほとんど知られていないのが現状ですが，優れたオブジェクト指向開発者を目指すならデザインパターンよりまずこっちを理解し覚えてしまいましょう． これらの法則は，絶対守らなければならないというものではありません．開発中に法則が守られているか意識することが重要です．つまり 今行っている設計はその法則が守られているだろうか その法則を破っている場合，破るべき正当な理由があるだろうか と絶えず考えるようにしましょう．そうするとそれは自然に優れたオブジェクト指向設計になるのです．つまりこれらの法則は，優れたオブジェクト指向開発のための指針なのです． Robert C. Martin の Principles of OOD Robert C. Martinは，オブジェクト指向設計の
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
