Java EEや.NETはCOBOLやVB6よりも本当に生産性が高いか？ - 達人プログラマーを目指して
プログラミングと設計は本来切り離せないものなのではがすごい反響だったのですが、結局この記事で私が言いたかったことは、 Java EEなどの現代的な開発環境はCOBOLなどの古い言語を使った開発とは根本的に設計の手法が異なる 多くの現場では未だに古い設計手法を使っているため、オブジェクト指向などの最近の開発環境のメリットが活用できず、低い生産性にとどまっている。 ということに要約できると思います。ただし、どうして、Javaではオブジェクト指向で開発しないといけないのか、どうして昔ながらの伝統的なやり方を改め、新しい設計手法を採り入れないといけないのかと疑問を持たれた方もいらっしゃるかもしれません。ここでは、開発手法と生産性の問題について、もう少し掘り下げて検討してみたいと思います。 レガシー言語の生産性 最近のCOBOLでは、オブジェクトやスタック変数すら使えますが、ここではCOBOL85の
クラス設計に関するメモ
経験的にこのようにした方がよいと思った点についての記録です。 仕事で大規模(2000クラス超)かつ製品寿命がながいパッケージソフトを作っていた関係で、 ちょっとした設計の間違いが、 あとあとで大変な苦労する羽目になったりすることを経験してきました。 このような規模が大きいアプリケーションを作ることはなかなかないかもしれませんが、 なにかの参考になれば、と思います。 継承する前に委譲を検討する Singleton パターンを使うときの注意 Template Method パターンを使うときの注意 クラス間の依存に関する注意 クラスの粒度 Singleton の問題を回避できるか？ 継承する前に委譲を検討する 継承はスーパークラスの仕様をよく理解しておかないと、 バグを作りこみやすいので十分注意する必要があります。 メソッドのオーバーライドをするときも、 public void foo(){
ジェネリクスの代入互換のカラクリ - プログラマーの脳みそ
Javaジェネリクス再入門 - プログラマーの脳みそでは、「変数の型の宣言」の項で「ジェネリクスの<>の中は一般のJavaの型の代入互換性とは異なる。このことはよく覚えておかなくてはいけない。」と言ったものの、深入りはしなかった。 このあたりについて深入りしてみようじゃないか。 とりあえずサンプルコードはJavaで記述していくが、このあたりはジェネリクス指向の概念の部分だから、あまり言語に依ることはない。便宜的にJavaで書く、としておこう。 まず、型変数の境界について考えるために以下の継承関係のクラスを用意しておく。 public class A {} public class B extends A {} public class C extends B {} public class B2 extends A {} public class C2 extends B {} これは図で
Javaジェネリクス再入門 - プログラマーの脳みそ
ジェネリクスでは、「型」を変数にした「型変数」というものを取り扱う。型変数で何が嬉しいかというと、メジャーな例ではコレクションAPIが挙げられる。java.util.Listとかjava.util.Mapとかのデータを格納するタイプのユーティリティクラスのことだ。 2004年にJavaのバージョンが5.0となるまでは、Javaにはジェネリクスの機能はなかった。なので、Listにデータを格納し、取得する場合は List list = new ArrayList(); list.add("hello!"); String str = (String) list.get(0); といったソースコードになる。 add()の引数はObject型で宣言されており、どんな参照型でもadd()することができた。 get()の戻り値もObject型で宣言されておりキャストが必要だった。このキャストはプログラ
再帰的ジェネリクスの代入互換性 - プログラマーの脳みそ
Javaのややこしいジェネリクスの話をしよう。*1 再帰的ジェネリクス クラスHogeがあったとして、型変数Tを取る。 public class Hoge<T> {} このHogeの型変数Tがextends Hogeとすると public class Hoge<T extends Hoge> {} すると、T extends Hoge の Hoge が raw型だと警告される。Hogeの<>の部分にHoge型を継承した型を指定しなければならない。ここで型変数T が extends Hogeだったので、丁度いいからT型をおさめよう。 public class Hoge<T extends Hoge<T>> {} これは再帰的ジェネリクス(recursive generics)と呼ばれているようだ。 追記：僕は勝手に自己言及型ジェネリクスなどと呼んでいた。情報サンクス！併せてタイトルなども表現
monodroid: API design - ものがたり(旧)
これは http://monodroid.net/Documentation/API_Design の現時点での日本語訳。 概要 MonoDroidでは、Monoのコア基本クラスライブラリに加えて、さまざまなAndroid APIのバインディングを提供しており、これによってネイティブAndroidアプリケーションをMonoで開発できるようになっています。 MonoDroidのコアには、C#その他の.NETの言語からJavaのAPIにアクセス出来るようにするための、C#の世界とJavaの世界を橋渡しする相互運用エンジンが存在しています。 設計原理 MonoDroidのバインディングにはいくつかの設計原理があります。 フレームワーク設計ガイドラインに準拠します 開発者がJavaクラスをサブクラスできるようにします サブクラスではC#の標準の構成概念が機能するはずです 既存のクラスからの派生 基
そろそろIDEよりコマンドラインのほうが理解が深まるという有害な妄想は捨ててはどうか？ - きしだのはてな
「Java入門ブックガイド（入門編)よりよき入門書と出会うために」を読んで。 第一印象として、よりよきJava入門ブックガイドに出会う必要があるなということ。 コマンドラインでは慣れ親しめない サブタイトルに「慣れ親しむことが上達の秘訣」とあるけども、コマンドラインで慣れ親しむのは難しいと思います。 「慣れ親しむことが上達の秘訣」が正しいのであれば、IDEで慣れ親しんだほうが上達するのではないでしょうか？ 現実問題として、書籍を買って勉強する人は強制されて勉強するわけではないです。自分の時間をやりくりして入門書を読んでいます。 そして、まだプログラムの面白さを知りません。 コマンドラインでコンパイルエラーが出たとき、じっくりとそのエラーを読み解くのではなく、そこでくじけてやめる可能性が高いと思われます。 それよりは、IDEでエラーを入力段階で修正しつつ進むほうがいいと思います。 javac
オープンクラスとはダイナミックスコープだという話。 - 言語ゲーム
http://blog.livedoor.jp/dankogai/archives/51507869.html を読んで、これは書かなきゃ！と思ったので、まだ考え途中だけどメモします。私のネームスペース理論で言うと、オープンクラスとはダイナミックスコープなのです。 まずオープンクラスとは何かざっと復習。Java 等の静的なオブジェクト指向言語では、クラスを定義する時に全部のメソッドを書く必要があるけど、Smalltalk や Ruby のクラスでは、あとからメソッドを追加したり書き換える事が出来ます。こういうのをオープンクラスと言います。オープンクラスの凄い所は、メソッドを変更する前にもともとあったプログラムの振る舞いまで変わってしまうと言う事です!これは柔軟であると同時に大変危険な諸刃の剣です。 次にダイナミックスコープとは何かをざっと復習。変数が使われている場所ではなく、処理の流れを元
Python のクラスメソッド – デコレータ @classmethod, @staticmethod を使って
1. メソッドをクラスメソッドにするときは、デコレータを使う あるメソッドをクラスメソッドにするとき、 Python ではデコレータを使うことができる。 2.1 組み込み関数 によると、(太字は引用者による) classmethod( function) function のクラスメソッドを返します。 クラスメソッドは、インスタンスメソッドが暗黙の第一引数としてインスタンスをとるように、第一引数としてクラスをとります。クラスメソッドを宣言するには、以下の書きならわしを使います: class C: @classmethod def f(cls, arg1, arg2, ...): ... ふーむ、ここでも第一引数が必須で、それがクラスを参照するということか。Python のこういう書き方は、最初とっつきにくいと感じた。 (+_+) デコレータの書き方としては、関数の前に @classmeth
)
メソッド (計算機科学) - Wikipedia
メソッド (method) あるいはメンバー関数 (member function)とは、オブジェクト指向プログラミングにおいて、オブジェクトに関連付けられた関数または手続きであり、オブジェクトの状態を操作したり振る舞いを実現したりするために外部から呼び出されるプログラム要素である。 オブジェクト指向プログラミングにおけるメソッドという用語は元々SmalltalkによってSimulaのメンバープロシージャー (member procedure) をメッセージとメソッドに分けるために導入された。C++ ではメンバー関数と呼ばれるが、これはSimulaのメンバープロシージャーをC言語に流用したことに由来している。Javaのような言語やマイクロソフト[1]などの企業がメソッドという用語を使っているのは、元々C++よりもSmalltalkの影響を受けていたためである[要出典]。近年[いつ?]では言
【Visual Studio Code】1.0 GAリリース予定日、決定！ - 好きな技術を好きと言える幸せ - AYA TOKURA BLOG - Site Home - MSDN Blogs
Microsoft Developer Blogs Get the latest information, insights, and news from Microsoft. AI agents are quickly moving from experiments to production‑critical components of modern applications. But while many teams know how to build agents, far fewer are confident they’re hosting them on the right foundation. Most organizations start by deploying agents the same way... We're shipping two major capa
Javaのラムダ式導入に関する最新提案の雑なまとめ - 矢野勉のはてな日記
java7月頭に，Brian GoetzがJavaにおけるラムダ式導入に関する最新提案のドラフトを出しました。State of the Lambda 私はこの提案書と，提案書を元にした英語記事を読んだだけですが，Twitterで話していると，23日くらいにこの提案を元にしたソースがJavaのソースリポジトリにコミットされたらしい。ただし，中ではまだ議論続発してるらしい。ちなみに英語記事はラムダについての連続記事の4回目で，5回目ではWicketでラムダ式を使うとどうなるか，という考察が載っています。提案書のラムダ式とWicketの非整合部分についての考察で，Wicket好きの人は読んでみてもいいと思う。あと，空コンストラクタがないクラスについて提案書は明確なところ書いてないよね，みたいな指摘も。せっかくなんで，最新提案におけるラムダ式実装をまとめておきます。いままでのあらすじ最新提案書では
現実のStroustrupインタビュー：C++は単にオブジェクト指向言語でない理由をC++の父は語る | taro-nishinoの日記 | スラド
10年以上前、Bjarne Stroustrup博士の偽インタビュー記事（又はパロディとも言う）がネット上で出回ったことがありました。C++の人ならよく御存知だと思います。幸いにもこことかここに、その和訳があります。その当時、これを本当のインタビューだと信じる（もしくは信じたい？）人が少なからずいて、鬼の首を取ったかのように自身のサイト（まだブログが流布する前なので）上で論評し、勝利宣言（？）か何かのように勝ち誇ったことがありました。どこの国かを言及すると、また私の愛国精神云々する単純細胞な人がいらっしゃいますので、あえて言いません。残念ながら、それらのサイトは当り前ですが削除、改訂されて、もう見ることは出来ません。 私が最初に原文を読んだ時、（今だから言うのではありません）偽だと思いました。日頃から博士の原文（書き言葉であろうが話し言葉であろうが）を読み慣れている人ならば、内容の吟味をす
不完全にしてかなり言葉足らずな比較プログラミング言語学 - 西尾泰和のはてなダイアリー
プログラミング言語は人が作ったもの。人は誤るもの。なので完璧なプログラミング言語は存在しない。 「人は誤るもの、しかし誤りに固執するのは馬鹿の所業だ。」(キケロ) プログラミング言語も、間違った設計をして、馬鹿でない人がそれを修正することの繰り返しで発展してきた。 というわけで言語間での設計判断の食い違いとか失敗した設計とかを収集中。一部抜粋して講義資料に入れるつもりなので他の事例をご存知でしたらぜひ情報をいただけるとありがたいです。 if(x = 0) C言語では代入が式であるためif(x == 0)のつもりでif(x = 0)と書いてしまい、常に偽になってしまう。 x = 0の値はint、条件式はboolでないといけないので型エラーだよ派: Java x = 0は式ではないので条件式に入れたら構文エラーだよ派: Python 条件式にx = 0をいれたらx == 0と解釈するよ派: H
メソッドの最後でしかreturnを書いてはいけない時 - プログラマーの脳みそ
柴田 芳樹 (Yoshiki Shibata)：So-netブログに出てくる、「メソッドや関数の最後でしかreturn文を書いてはいけないと、プロジェクトの標準として何らかの方法で強制」された場合、機械的な書き換えを行うことで対応することが出来る。 まずは戻り値がvoidのメソッド。条件分岐などでreturnしているようなケース。 public void hoge1a(boolean b) { if (b) { System.out.println("true"); return; } else { System.out.println("false"); return; } } これはラベル付きブロック+break文に置き換えることで単純に置換できる。 public void hoge1b(boolean b) { ret:{ if (b) { System.out.println("t
次世代の基幹系オープンシステム開発に利用されるプログラミング言語は？ - forest book
2009/06/14 に再チャレンジ 業種/職種別に今から勉強しようと考えているプログラミング言語は？ 先日、SIer の友人が新人研修の講師として Java を教えるというお話を聞きました。会社側からは「Java を教えるのではなく、"プログラミング" を教えてほしい。オブジェクト指向は教えないでください。」との指示を受けたそうです。 会社側の意図としては、オブジェクト指向が云々とか、抽象クラスを使って、、、とかを覚えても、新入社員が現場に配属されて、即戦力で活躍とまではいかなくても、まともにさえ機能しないというクレームが出ているそうです。 やや暴論ですが、研修をやっても現場で使えないならば、研修なんかやらずにすぐに現場に配属して、そこでたたき上げで学べという事だそうです。 そんな事が頭に残っていて、SIer で流行る次世代のプログラミング言語って何だろう？と素朴な疑問が起こりました。
「C++ は難しいから」と言う定説 - Cube Lilac
雑記． C++ は難しいから Java から始めた方が・・・ ここ最近（と言うか以前からずっとですが），上記のようなアドバイスを見かける機会が多かったせいか「C++ の何を指して（Java と比べて）難しいと言っているのだろう？」と言う事を単純に疑問に思うようになりました．Java 自体はほとんど使ったことないのですが*1，感想としては「どちらも大して変わらない」と言うものだったので余計に気になっています． 以下，現状で私が「これが要因かなぁ」と思っている事を列挙してみます． C++ には XXX と言うクラス/関数がない 可能性として一番高いのはこれかなぁと思っています．C++ の標準ライブラリは必要最低限のものしか（必要最低限のものさえも？）用意されていないので，他の言語と比べてライブラリの貧弱さは目立ちます．Boost を含めればかなりマシになりますが，それでもキツいかなと言う印象を
バベル案内
Steve Yegge / 青木靖 訳 2004年9月 これは駆け足の言語案内だ — Amazon Developers Journalのために今月書いていたのだが、どうもこれを見苦しくないようにする方法を見つけられなかった･･･。 ひとつには、私はどうも粗野で口汚くなりがちで、オフィシャルな趣のあるAmazonの出版物に載せるのは不適切に思えた。それでかわりに誰も読まない自分のブログに押し込めてしまうことにした。読んでるのはあなたくらいのものだよ。どうも! もうひとつ言うと、これは本当に書きかけのものであり、そこかしこの断片を集めたものでしかない。全然磨き上げられていない。これもブログエントリにする理由になっている。ブログなら別に良質である必要も完全である必要もない。単に私が今日考えたことというだけのものだ。ではお楽しみを! この駆け足の案内では、C、C++、Lisp、Java、Perl
RubyからScalaに乗り換えた15くらいの理由 - ヽ( ・∀・)ノくまくまー(2010-04-26)
● [Scala] RubyからScalaに乗り換えた15くらいの理由 [注意] この文章を読むと、既存のRubyコードをScalaでrewriteしたくなる、 Rubyコードで型チェックをやるのが鬱になる、Ruby案件でやる気が出なくなる、 などの幻覚や異常行動が報告されています。 現在関わっているプロジェクトや家族のことを常に意識し、 気を強く持って冷静に読むとよいでしょう。 「Scalaプログラミング入門」を読みはじめて、いきなり大きく頷いてしまった。 "コーディング時間の半分をテスト作成に費やさなければならなかった"(p.3) "Railsによって得られた生産性の向上は、テスト作成の作業に失われてしまいました"(p.3) まさにここ数年私が抱いてた漠然としたストレスの正体が、的確に文章となっていたからだ。そしてほどなく、「あ、この機能がRubyに欲しかった！」という驚きと共に Sc
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
IBM Developer
