憂鬱本を買ってみました - みねこあ
javablack さんが最近とりあげ、 ちょっとだけ話題再燃したの憂鬱本 こと「憂鬱なプログラマのためのオブジェクト指向開発講座」。以前借りて読んだことがあるのですが、「酷いわ」と思ったこと以外具体的なことは何も覚えていません(^^; で、具体的になにが酷かったのかのかな？とザザッとWebを流してみたのですが、見つからない。というか「これはいい本だー」という感想ばっかりで、予想以上に「酷い」というレビューがないのに改めてビックリです。 むー、これはネチっこいレビューの需要があるかな？とスケベ心をだして買ってしまいましたョ。 憂鬱なプログラマのためのオブジェクト指向開発講座 (DDJ Selection) 作者: Tucker出版社/メーカー: 翔泳社発売日: 1998/05/31メディア: 大型本購入: 10人 クリック: 508回この商品を含むブログ (78件) を見る で、改めて読み
実はオブジェクト指向ってしっくりこないんです！：気分はstatic！：エンジニアライフ
わたしはこれまで、C言語、Visual Basic、SAP ABAP、最近になって ASP.NET C# などの言語を使ってきた。 「自分でクラスを作ってオブジェクト指向っぽいことをしている」なんてことはまったくない。特に「メンバー関数をstatic宣言すればインスタンス宣言をしなくてもいい」ということ知ってからは、メンバー関数を従来のファンクションのように使っている。共有変数も、pubulic static宣言していまう。したがってプロパティなんて作らない。 staticを理解していない人のコードを見ると、いちいちインスタンス宣言しているので笑ってしまう。データベースにアクセスするアプリケーションをC#で書いているのだが、Visual Studioで供給しているSQL関係のクラスを使えばできてしまうのだから。 オブジェクト指向の入門書では、クラスが持つ隠ぺい性が強調されているが、これは他
依存関係逆転の原則
チェストの依存関係 私たちの身の回りにあるものは、たいてい細かいオブジェクトが大きなオブジェクトに依存しています。 たとえばチェスト。 チェストには枠と引き出しがありますね。 引き出しは、チェストの大きさによって3つくらいだったり、7つくらいだったりします。 これ、枠と引き出しの依存関係はどうなってるんでしょう？ 枠が引き出しに依存してるんでしょうか？ 引き出しが枠に依存してるんでしょうか？ 先に枠があって、それにあわせて引き出しが作られたんでしょうかね？ とすると、引き出しが枠に依存しているといえそうですね。 んー、先に引き出しがあって、それに合わせて枠を作るってのは、なんか不自然なカンジですね。 とすると、やっぱり引き出しが枠に依存してるのかな。 と、ちょっと待ってください。 この問題、そもそものスタートから間違ってます。 誰も、なんにもなしでいきなりチェストの枠を作り出したり、引き出
Java EEや.NETはCOBOLやVB6よりも本当に生産性が高いか？ - 達人プログラマーを目指して
プログラミングと設計は本来切り離せないものなのではがすごい反響だったのですが、結局この記事で私が言いたかったことは、 Java EEなどの現代的な開発環境はCOBOLなどの古い言語を使った開発とは根本的に設計の手法が異なる 多くの現場では未だに古い設計手法を使っているため、オブジェクト指向などの最近の開発環境のメリットが活用できず、低い生産性にとどまっている。 ということに要約できると思います。ただし、どうして、Javaではオブジェクト指向で開発しないといけないのか、どうして昔ながらの伝統的なやり方を改め、新しい設計手法を採り入れないといけないのかと疑問を持たれた方もいらっしゃるかもしれません。ここでは、開発手法と生産性の問題について、もう少し掘り下げて検討してみたいと思います。 レガシー言語の生産性 最近のCOBOLでは、オブジェクトやスタック変数すら使えますが、ここではCOBOL85の
「疑り深いあなた」はインスタンスをOOPの本質と言われて納得できるのか - みねこあ
私が、なぜオブ本書評で前橋さんの講義「疑りぶかいあなたのためのオブジェクト指向再入門」を OOP じゃない、と言った問題について、神様なんて信じない僕らのために さんで議論になっています。 関数はひとつしかない事が問題なの？ - 神様なんて信じない僕らのために 続・関数はひとつしかないことが問題なのか？ - 神様なんて信じない僕らのために 複数個を前提とした設計はオブジェクト指向で綺麗な設計か？ - 神様なんて信じない僕らのために で、最後のの、前橋さんのコメントを読んで、思ったこと/言いたいことが出て来てムズムズしてしまいました。あぁ、あたしんちに書いてくれたらうれしかったのに。で、Isoparametricさんちの コメント欄にいろいろ書きかけたのですが、例によって肥大化してしまったですし、ちょっとヒトのウチで場外乱闘はどうかな？、と思い直して自宅にてエントリーをば。 ひとつめ、 抽象
多くの日本人がオブジェクト指向プログラミングを苦手とするのは英語アレルギーだからか？ - 達人プログラマーを目指して
やはり、多くの人からいろいろなコメントをいただくと、意外な発見がありおもしろいです。 プログラミングと設計は本来切り離せないものなのでは - 達人プログラマーを目指して のブクマのコメントに 何か、主語がないから理解が難しい読み物 というのがありました。私の文章の拙さをまずは反省しなくてはなりません。ただ、普段から日本語を話したり、文章を書いたりする際にはあまり意識していなかったのですが、よくよく考えてみると日本語の文章で「主語」と呼ばれるものがなんとなく省略されることも多いように思えてきました。中学校の国語の授業では「は」や「が」という助詞がついた言葉が主語であると習ったと記憶しているのですが、実際に、文中で明示的にそのような文節が表れない現れないことが多いように思います。 そこで「日本語 主語」で検索してみたら、非常に興味深い記事がいくつか見つかりました。 http://www.geo
業務システムでオブジェクト指向は必要か？ - 達人プログラマーを目指して
半年前に爆発的に盛り上がったネタで今更ですが、 実はオブジェクト指向ってしっくりこないんです！：気分はstatic！：エンジニアライフ について。多態性（ポリモーフィズム）やGoFのデザインパターンなどの常識を知らない筆者が、C#でpublic staticメソッドを使えば*1インスタンス化が不要などと知ったかぶりの口調で説明したところ、コメント欄やその他のブログで爆発的に議論（多くは反論）が巻き起こったという、伝説的な内容の記事です。多くの方が既にコメントしているので、ここでは筆者の無知や態度については繰り返し言及しないことにします。ユーザー企業のIS部門という業界のピラミッド構造のかなり上の方に属する立場のSEにはこの程度の見識しか持たない人もいるのか、井の中の蛙の技術者とはこのようなものなのかという事実をあらためて世に知らしめたという意味で、（炎上した多数のコメントも含めて）非常に貴
開放・閉鎖原則
今回は、開放・閉鎖原則のお話です。 これも、リスコフの置換原則と同じかそれ以上に、ソフトウェア開発者の方には有名な原則ですね。 これも、開発の現場では、みんな知ってるにもかかわらずないがしろにされがちな原則です。 英語でopen・closed principleですので、OCPと略されたりもします。 ソフトウェア開発者でない方には、この原則の概念を理解していただきたいと思います。 この原則によって、あなたの生活からストレスが軽減される…かもしれません。 ソフトウェア開発者の方には、この原則の重要性を再認識していただきたいと思います。 コンテンツ計画は、細かければ細かいほど失敗しやすい例： 旅行計画オープンでクローズドオススメ計画は、細かければ細かいほど失敗しやすい 何か重要なやるべきことがあるとします。 すごく楽しみにしてた観光だとか、失敗できない仕事だとかそういうことです。 そんなとき、
リスコフの置換原則（LSP） - Strategic Choice
リスコフの置換原則（LSP:the Liskov Substitution Principle）派生型はその基本型と置換可能でなければならない。どういうこと？使う側から言うと、基本型を引数にとる関数に、どんな派生型のインスタンスをもらっても気にしないで使えないとダメ。実装側から言うと、派生クラスがその基本クラスで使われるところにおいても、正常に動作することを保証しなければならない。なんで？使う側に意識させるということは、OCPに違反することになるから。つまり、LSPに違反すると、必然的にOCPにも違反してしまう。たとえば？ではまず、簡単な例。Shapeクラス、そしてその派生クラスCircle/Squareがある。Shapeにabstract関数を使わない。Circle/Squareにそれぞれ独自のDraw関数がある。ここでShapeを受け取ってDrawする関数を作ろうとすると、、、、 v
プログラミングの基本はIF文を極力排除する - プログラマの思索
小川 明彦, 阪井 誠 : チケット駆動開発 日本のソフトウェア開発の現場で生み出された「チケット駆動開発」という概念を、数多くの実例を元にモデル化・体系化を試みた最初の本。 小川 明彦, 阪井 誠 : Redmineによるタスクマネジメント実践技法 Redmineによるチケット駆動開発の実践技法に関する最初の本。アジャイルなソフトウェア開発への適用方法、TestLinkによるテスト管理手法についても言及。 清水 吉男: 「派生開発」を成功させるプロセス改善の技術と極意 組込システム開発をベースとして、ソフトウェア開発特有のスタイルである派生開発、特にXDDPについて解説した世界でも稀な本。既存製品を保守するのではなく継続的に機能追加していく昨今の開発では、派生開発特有の問題を意識しなければならない。XDDPはプロセス論だけでなく、要件定義などの上流工程の品質改善にも役立つので注意。 Le
私がJavaからC#に乗り換えた10の理由 - 個人事業主のつぶやき
私がJavaからC#に乗り換えた10の理由という、コラムが@ITにあった。 面白い話だったので、ここで紹介しておく。 ついでなので、私の意見も織り交ぜることにする。 - 理由01 - struct C#では、class以外にstructがある。双方の違いは ヒープ領域に置かれるか、スタック領域に置かれるかの違いだ。 コラムでは、これが大問題にあるとあるが、そんなことは感じたことがない。 最終的に、そうせざるを得ない場合があったとしても、 Poolクラスを作ってしまえば、ヒープ領域の無駄遣いはほぼなくなる。 私は逆にC#の方が使い勝手が悪いように思える。 C#をしっかり押さえている技術者は間違わないが、 スタック領域とヒープ領域を知らない技術者も多い。 そんな技術者がstructをゴリゴリ作ったらどうなるか・・・ スタック領域はかなり限られているので、スタックオーバーを起こす方が簡単だ。 -
enum-j.html#java_enum
C言語によるプログラミングでは、列挙型(enum型)はたいへん良く使われます。 オブジェクト指向言語でも、それは変わらないようです。C言語を拡張したC++言語ではもちろん、Java言語でも、J2SE 5.0になってから列挙型が導入されたほどです。 その一方で、オブジェクト指向言語で列挙型を使う弊害も、繰り返し指摘されてきました。列挙型とswitch文を使ったソースコードは、ポリモーフィズムを使って書き直すべき典型的な悪い例として、しばしば取り上げられて来ました。 しかし、列挙型を使ったプログラムのすべてが、ポリモーフィズムを使って書き直すべきだとは限りません。継承によるポリモーフィズムは、オブジェクト指向の特徴の１つですが、サブクラスを作るべきではないケースもあるのです。そのような場合に、列挙型を使ったコードを書くことは、悪いことではありません。 ここでは、オブジェクト指向言語における列挙
特別公開！アーキテクチャドキュメント｜オブジェクトの広場
はじめに この記事では、以前私たちが実際に関わった開発案件で作成した「アーキテクチャドキュメント」を公開します。 別に国宝のお寺の庭に入れるわけでもないのに、「特別公開！」などという表現はずいぶん仰々しいな、と思われる方もいらっしゃるかもしれません。しかし特定のお客様向けに作成し納品したドキュメントを、そのまま外部に公開してしまうような例を、私自身はあまり聞いたことがありません。 これって結構特別だと思うのですが、手前味噌でしょうか？ システムの概要 ご紹介する開発案件の名称は「新石炭総合ＯＡシステム」といいます。これは、宇部興産株式会社殿で使われる社内システムで、在庫管理、販売管理などの機能を提供する典型的なビジネスアプリケーションです。 開発主体は株式会社宇部情報システム殿です。弊社（オージス総研）は、プロジェクトの立ち上げ期間の約３ヶ月間、２名が参加し、概念モデリングのコンサルティン
Java の enum - ぐるぐる～
イマドキの Java には enum があるんですよ実は、という話。 知ってるよそんなこと！な人は読むまでもないかも。 enum って？ 列挙型のこと。C とか C++ とか C# とかでおなじみのアレ。 単純な enum は Java でもこれらの言語の enum と同じような記述になるけど、これらの言語の enum が整数型をベースにしているのに対して、Java ではオブジェクトをベースにしている点が異なる。 まぁその話は後ほど・・・ 単純な enum ただ列挙するだけの enum なら、本当に C や C++ や C# とほとんど変わらない。 // 信号機の色 enum SignalColor { RED, BLUE, YELLOW } ただこれだけ。末尾には、余分なカンマがあってもいい。 enum SignalColor { RED, BLUE, YELLOW, } 更に、末尾にセ
Java言語でのガベージコレクションと変数のスコープとの関係について教えてください。…
Java言語でのガベージコレクションと変数のスコープとの関係について教えてください。以下のプログラムをコンパイル／実行したところ、 mylist = 10 mylist = 110 mylist = 210 <<中略>> mylist = 910 という結果になりました。変数tmpのスコープは最初のforループが終わったところなので、生成したインスタンスもそのときに破棄されると考えていたのですが、実行結果を見る限り違うようです。変数のスコープとガベージコレクションのタイミングは別と考えてよろしいのでしょうか？ できましたら、該当するJava言語仕様へのリンクも示していただければ嬉しいです。 以上、よろしくお願いします。 --- ソース --- import java.util.*; class sample { public static void main(String[] arg) {
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
IBM Developer
Administrative Quarantine
Loading...
http://www.crew.sfc.keio.ac.jp/lecture/2002objprog/kougi/kougi14/kougi14.ppt
サービス終了のお知らせ