例の OOP の三大要素「カプセル化（≒情報隠蔽）」「継承」「ポリモーフィズム」は、有名なわりには「詠み人知らず」で、しかもあまり良いモノではありません。 sumim さんによれば、もともとはC++でのOOPを説明する要素から「抽象データ型」「継承」「動的結合」の三つが抜き出され、その後変化した物だと思われるそうです。(オブジェクト指向の概念の発明者は誰ですか？(改訂版) - Smalltalkのtは小文字です)。 そのようは背景から、「三大」は 静的OOPLに偏っており、しかも C++ 界隈ですら、C++ プログラミングスタイルの進化から取り残され、古びて現状に一致しなくなっており、21世紀に入ってからのまともな C++ 本で そのままを使っているのをわたしはみたことがありません。 この「三大」を 「OOPとは何か」の文脈で 取り上げるメリットはもうないのです。（デメリットならたくさんあ
文化祭でカセットコンロ４台の上に鉄板２枚載せて焼きそばを作っていたらガスボンベが爆発、生徒１５人負傷…私立豊南高校
某所のチャットで話題になって、流れ去りそうだったのでもったいないから転載しておいた。事後承諾で。 MIYAMOTO Daisuke: 型の継承と実装の継承を区別する方法がないんだよな。 西尾泰和(nishio.hirokazu): 型を継承させずに実装を継承させたい→それ移譲で ってことかな？ MIYAMOTO Daisuke: そそ。そもそも、クラスに「型としての役割」と「実装としての役割」という複数の責務があることに、俺は長い間気づかなかった。これに気づかないと、型継承と実装継承が頭の中で整理できない。 西尾泰和(nishio.hirokazu): 僕が最近気づいたことも加えると、クラスには「ユーザ定義型」「インスタンスを作成する道具」「実装の再利用の単位」という3つの役割がある。 MIYAMOTO Daisuke: あぁ、インスタンスの生成器ね。 西尾泰和(nishio.hiroka
設計の観点から見ると、「クラス継承」には２通りのやり方がある。１つは今まで見て来たような Java のクラス継承に関する言語的機能を使うものであることは当然である。もう１つは「委譲」と呼ばれ、形式的にはクラス継承ではないのだが、クラス継承とほぼ同様の効果を得ることができる。 あるクラスを継承する場合、普通にクラス継承(inherit)すれば次のようになる。 class Base { private int x, y; public int methodA( ) { ..... } /* このクラスは上書きされる */ public int methodB( ) { ..... } /* このクラスは上書きされない */ } class Delivered extends Base { public int methodA( ) { /* 基底クラスの上書き */ super.methodA
オブジェクト指向プログラムで getter/setterメソッドを使わなければならない 10の理由 福盛 秀雄 fukumori at m.ieice.org JavaやC++などのオブジェクト指向言語でプログラムを書いているときに、単純なメンバ変数を参照したり操作するために anObject.getX() [以後これをgetterメソッドと呼ぶ] とか anotherObject.setY(y) [以後これをsetterメソッドと呼ぶ] と書くのはなぜだろうと思ったことはないだろうか? int型の変数ひとつを操作するのになぜわざわざメソッドを定義するのだろう? 単純に代入を使えばいいじゃないか? この文章はそんなあなた(かつての僕も含む)が、getter/setterメソッドを使うべきである理由についてまとめたものである。 ということで早速本論へ。 1. クラス内部のデータ表現を変えた場
プログラムを書く人にとって、クラスとは何なのでしょうか。 シンプルな例を出して考えると理解が速いですよね。 class A { public: string name_; int price_; }; 名前と値段のフィールドがありますね。 はい。クラスとはデータ集合の定義のことです。 ですがこれだけでは使いようがありませんね。 では次の例を見てください。 int main() { int i; double d; A a; } int, double, … と同じように A を使っていますね。 クラスとは型なのです。*1 おっと、忘れていました。 実はクラスには関数を定義する機能があるのです。 class A { public: string name_; int price_; string to_string(); // 名前と値段を用いて文字列を生成する。 }; はい。クラスとはデー
コラム「システムエンジニア 生き残りの極意」でちょっとした祭りになっている件 - babydaemonsの日記 ポリモーフィズム（多態性）を知らずにオブジェクト指向という単語を口にするなー！！！ という悲痛な叫びを読んでふと思い出したのでメモ。 以前、会社の技術者向け新人研修でJavaを教えたとき、ポリモーフィズムの概念を理解してもらうときに使った例え。 「ポリモーフィズム==ガチャピンチャレンジ」説 要は、ガチャピンの着ぐるみ（Javaで言うインターフェイス）に"何かチャレンジしろ"というメソッドを定義する。「中の人」が入れ替わることで、"何かチャレンジしろ"というメソッドを実行したときの処理内容は変化するけど、視聴者（呼び出し元）から見れば「中の人」がスキーヤーだろうが格闘家だろうがレースドライバーだろうが、全てひとくくりに「ガチャピン」として扱うことが出来るので便利。ひたすらifで処
日本のホワイトカラーの生産性を上げるには、データベース設計をプログラミングの後に行うべき、そのためにはビジネスロジックをストアドプロシージャに入れる必要がある。ということを前回書きました。 今回は、具体的にどうしてストアドプロシージャが効率が良いかということを書きたいと思います。 オブジェクト指向言語に限りませんが、一般的な開発は以下の図1の様になります。 図1 オブジェクト指向での開発 私のいうストアドプロシージャでの開発は以下の図2の様になります。 図2 ストアドプロシージャでの開発 オブジェクト指向言語で処理する場合、図1の「４．」の繰り返しが多ければ多いほどパフォーマンスが悪くなります。 ですから、よくパフォーマンスが悪ければ「４．」繰り返しを減らすように図1の「１．３．４．」の処理を修正すればよい、つまり、パフォーマンスが悪いときSQLで処理する部分を増やす。という主張を耳にする
ガール・ミーツ・スーパーガール 今年はサンマがたくさん獲れているらしい。 どのスーパーに行っても今が旬だよ、今日とかめっちゃお買い得だよ、みたいな感じで売られている。実際キラキラしていておいしそうだ。でも乱獲が問題視されてなかったっけ？私が婆さんになっても海にはサンマが泳いでいてほ…
社内の精鋭エンジニアを中心に定期的に勉強会をすることになった。んで、 JavaScript の講義は僕がやることになった。 資料を社内だけでとどめておくのはもったいないので、ここに公開していきます。社内の人も社外の人も読んでください。 講義の内容は基本的にソース嫁。ソースレビュー形式。 ※ターゲットは JavaScript は書いたことない、オブジェクト指向言語プログラマ。 Section 00 Prototype.js の前に JavaScript のオブジェクトの概要・・・ オブジェクトを作ってみる。 var object = {};オブジェクトにメソッドとかプロパティを追加してみる。 var object = { field: 'IT戦士', method: function() { alert('hello ' + this.field); } }; object.method()
なんか結論をタイトルに書いただけですべて言い尽くしてしまった感があるんだけど、一応書く。 設計の質が向上する 設計時点でクラスの責務とかメソッドの処理内容などを検討するとか、レビューなんかでも議論されるんだろう。そのときに同時に、クラスやメソッドの命名が的確になされているかをチェックすべきだ。 クラス名が的確ならばクラス名を見ただけで、そのクラスの責務が推測できる。これはとても重要なことで、例えば何かの機能追加をしようとしたときに、そのクラスに実装を追加すべきなのか、それとも別のクラスに追加すべきなのか(または新たなクラスを作成すべきなのか)、判断の拠り所にもなりうる。 メソッド名が的確ならば、メソッド名が意味している以上の処理を書こうとすると不自然になるので、自然とatomicなメソッドになりやすい。もちろん、気付かなかったらatomicにならないんだけど、ぼんやりしたメソッド名だった場
あなたにとって重要なトピックや同僚の最新情報を入手しましょう最新の洞察とトレンドに関する最新情報を即座に受け取りましょう。 継続的な学習のために、無料のリソースに手軽にアクセスしましょうミニブック、トランスクリプト付き動画、およびトレーニング教材。 記事を保存して、いつでも読むことができます記事をブックマークして、準備ができたらいつでも読めます。
おつかれさまです。そろそろ、プログラミングに関するエントリも書かなければw DDDの勉強を開始するにあたって、一番最初にEntitiesとValue Objectsに出会う。 今回は、まず先にValue Objectsと関連が深いImmutableについて、考えてみよう。なぜ、Value ObjectsかというとOODの基礎をなすからだ。基礎が弱いとその上の建造物ももろいものとなってしまう。だからValue Objectsがまず先。なーんだ、ただのJavaBeansなんでしょ、と思うと痛い目にあうよw 値を表すのがValue Objects。説明することが目的のオブジェクトである。ここに説明されているとおり。 ● Value Objects（値オブジェクト）パターン エンティティとは逆に、たとえば「色」や「量」のように、その属性だけが重要で、アイデンティティを考えることに意味のないオブジェ
あちこちのサイトを見てると、間違った解釈をしてるのが多い。カプセル化なんて、情報隠蔽まで含んでるのが常識になりつつあるような。。。ここまで一般化してると情報隠蔽してるのがカプセル化というのが常識なのかも。 カプセル化・情報隠蔽・データ抽象化 - 今日の役に立たない一言 − Today’s Trifle! − カプセル化と情報隠蔽、データ隠蔽の違いがよくわからくなったので、手持ちの本で調べてみた。 基準 基準としては、 カプセル化、情報隠蔽、データ隠蔽の関係 カプセル化は隠蔽を含んでいるかどうか 対象はクラスのみか、そうでないか などなど。 一番目はそのまんま。二番目は、 // 隠蔽せずともカプセル化か class Hoge { int hoge; // なんかhogeを使うメソッド } // 隠蔽しなければカプセル化ではないか class Piyo { private int piyo;
Java, FizzBuzz id:yojikさんからトラックバックをいただきました。こちらを読んでて、逆に純度100%のOO厨気分で考えるとどうなるか考えてみた。まずOO厨な考え方では「結果」を先を求める。1から100まで並んでるんだけど3の倍数の所は「Fizz」で、5の倍数のときはBuzzで、両方の倍数の場合はFizzBuzzが並んでる、FizzBuzzな仕様の「シーケンス」があればいい。シーケンス=繰り返し。ならばIteratorだ。いまさらFizzBuzz問題をOO厨がやるとどんなことになっちゃうのか - yojikのlogなるほど....面白い。 FizzBuzz問題の発端となった記事の「２分」に惑わされていて、自分でこの遊びに思い至らなかったのが口惜しい。Lispの件だってもはや「２，３分で」なんて話はどっかにすっとんじゃってて、「Lisp的にはどうやるか」という方向にシフトし
流れに乗り損ねたけども。 ソフトウェア工学は単一の方向を向いているものではない。というか、多様なジャンルがあるなかで「属人性を排除して開発者の能力を均一化しようとしている」なんて統一の目的感があるわけがない。 より高度なソフトウェア製品を作るには、ソフトウェア工学の成果を持って当たることになる。データマイニングの技術は属人性の排除か？まったくそんなことはない。ひとまとめに「ソフトウェア工学」と言ってしまうのはあまり本質的ではないと思う。 SI業務のふたつの仕事 さて、ソフトウェア工学のなかでも話のターゲットになっているであろうオブジェクト指向技術だとかの話。近年広く普及したオブジェクト指向だとかは、僕は高度技術を振るう作業と単純作業の間を分かつモノとして働いていると分析している。*1そして、単純作業をするのには特別の才能を必要とせず、SI業務はこうした頭数でこなされる部分が多い。ボリューム
オーバーライドの仕組みを紹介するために、Javaでクラスベースのオブジェクト指向の仕組み(オーバーライドメソッドの動的束縛部分のみ)を簡単に作ってみる。 オブジェクトの構造 まず、このオブジェクト指向システムで利用するオブジェクトの構造を作ってみます。 10行くらいでできる。 public class MyObject { private MyClass thisClass; // このオブジェクトが属するクラス public MyObject(MyClass thisClass) { this.thisClass = thisClass; } // メソッドの起動 public MyObject invoke(String name, MyObject...args) { // メソッドを自身のクラス情報から引き当てて実行 MyMethod method = thisClass.reso
Binstock on Software: Perfecting OO's Small Classes and Short Methods The Pragmatic Programmersシリーズの新しい本、The ThoughtWorks Anthologyの中に 興味をそそるエッセイがある。Jeff Bayの"Object Calisthenics"だ。 これは良いオブジェクト指向の性質を実証する小さなルーチンを書く方法をマスターするための 詳細にわたるエクササイズだ。オブジェクト指向なルーチンを書く能力を向上させたい開発者がいるなら このエッセイに目を通すことを勧める。ここにBayのアプローチを要約してみよう。 彼は次にあげられる制約のもとに1000行のプログラムを書くことを勧めている。 これらの制約は意図的に過剰な制限となっているが、これは開発者を手続き的なやり方から脱却させるた
1960 年生まれ，独身フリー・プログラマの生態とは？ 日経ソフトウエアの人気連載「フリー・プログラマの華麗な生活」からより抜きの記事をお送りします。2001年上旬の連載開始当初から，現在に至るまでの生活を振り返って，週1回のペースで公開していく予定です。プログラミングに興味がある人もない人も，フリー・プログラマを目指している人もそうでない人も，“華麗”とはほど遠い，フリー・プログラマの生活をちょっと覗いてみませんか。 ※ 記事は執筆時の情報に基づいており，現在では異なる場合があります。 前回の記事で「オブジェクト指向だからこそ悩む」という書き方をしたが，よく考えてみるとこれはあまり正しい表現ではない。なぜなら，オブジェクト指向プログラミング（以降，OOPと略す）の仕様を持ったプログラミング言語であるからといって，大抵の場合は必ずしもOOPを多用する必要があるわけではないからだ。 現に，少
今朝方Twitterでこのエントリを紹介したら、 オブジェクト指向談義が盛り上がったのでその議事録をば。 monjudoh とてもためになる読み物http://return0.dyndns.org/log/2008/08/10#s_2 monjudoh ＞「クラスベースのオブジェクト指向プログラミング言語はプロトタイプベースのそれの特殊ケースであり、プロトタイプベースは関数型言語で大抵はエミュレートできる、というか関数型言語のサブセットに近いと思ってる。」 nagise @monjudoh みねこあさんとこのエントリ読んでたら、自分の理解するOOPが実はOOPじゃないんじゃないかと思えてきて。 iratqq @monjudoh エミュレートは出来ても使い物になるものにするにはファーストクラスのマクロが必要で、つまりCL最強という話ですね、わかります。 deq @monjudoh クラスベー
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く