ドラゴンボールといえば、大変に人気の高い国民的、いや世界的な漫画、アニメですが、昨日匿名ダイアリーでドラゴンボールをネタにしたオブジェクト指向の解説がホッテントリに入っていました。 ドラゴンボールで学ぶオブジェクト指向 多くの人に親しみやすい題材でオブジェクト指向の考え方を解説するというのは非常に興味深い試みなのですが、オブジェクト指向の説明としては不適切なところがあり、ちょっと残念な内容になっています。私自身ドラゴンボールの専門家（ドメインエキスパート）ではないため、不正確なところがあるかもしれませんが、ストーリーを思い出しながら、私なりにドラゴンボールをネタとしたオブジェクト指向の解説にリトライしてみたいと思います。 なお、オブジェクト指向でもプログラミング言語によって表現できる内容が異なるため、当然設計技法は違ってきます。ここではJava、C++、C#、Visual Basicといっ
Javaは創成期に何を目指し何を解決したかったのか ― を考えることで、オブジェクト指向（プログラミング）に対する理解を深めることができます。 本連載は、非オブジェクト指向言語が持つ問題をJavaがどのように解決したかを知ることで、オブジェクト指向の本質を理解することを目的としています。非オブジェクト指向の代表格としてC言語を主として扱いますが後半ではC++の問題にも触れます。 （JavaやC++のように静的な（固い）オブジェクト指向プログラミング言語の問題を、Rubyなどの動的な（柔らかい）言語が、どのように解決したのかについて、別の連載テーマとして取り上げる予定です。） 「オブジェクト指向」という言葉（の少し歴史的な話） Java以前のオブジェクト指向はソフトウェア開発に直結する技術でしたが、Javaによって爆発的に「オブジェクト指向」という言葉が広まって以来、徐々に設計や要求定義と
プログラミングと設計は本来切り離せないものなのではがすごい反響だったのですが、結局この記事で私が言いたかったことは、 Java EEなどの現代的な開発環境はCOBOLなどの古い言語を使った開発とは根本的に設計の手法が異なる 多くの現場では未だに古い設計手法を使っているため、オブジェクト指向などの最近の開発環境のメリットが活用できず、低い生産性にとどまっている。 ということに要約できると思います。ただし、どうして、Javaではオブジェクト指向で開発しないといけないのか、どうして昔ながらの伝統的なやり方を改め、新しい設計手法を採り入れないといけないのかと疑問を持たれた方もいらっしゃるかもしれません。ここでは、開発手法と生産性の問題について、もう少し掘り下げて検討してみたいと思います。 レガシー言語の生産性 最近のCOBOLでは、オブジェクトやスタック変数すら使えますが、ここではCOBOL85の
今回は、開放・閉鎖原則のお話です。 これも、リスコフの置換原則と同じかそれ以上に、ソフトウェア開発者の方には有名な原則ですね。 これも、開発の現場では、みんな知ってるにもかかわらずないがしろにされがちな原則です。 英語でopen・closed principleですので、OCPと略されたりもします。 ソフトウェア開発者でない方には、この原則の概念を理解していただきたいと思います。 この原則によって、あなたの生活からストレスが軽減される…かもしれません。 ソフトウェア開発者の方には、この原則の重要性を再認識していただきたいと思います。 コンテンツ計画は、細かければ細かいほど失敗しやすい例： 旅行計画オープンでクローズドオススメ計画は、細かければ細かいほど失敗しやすい 何か重要なやるべきことがあるとします。 すごく楽しみにしてた観光だとか、失敗できない仕事だとかそういうことです。 そんなとき、
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
