いまさらですが、職業Javaプログラマーなら理解しておいてほしい「継承」の意味について - 達人プログラマーを目指して
正しく意味を理解している方にとっては、まったく常識レベルの話であり、何をいまさらと思われる方々も多いかと思いますが、大規模案件のレガシーコードなど、私が仕事で見かけるJavaのコードを読むと、「このコードを書いたSEやPGの方々は、はたして継承の意味を正しく理解していないのではないか」と思われる設計のコードに出会うことが少なからずあります。現在では改良されましたが（Javaプログラミング能力認定試験の問題がかなり改善されていました - 達人プログラマーを目指して）、以前のJavaプログラム認定試験の問題は、そうした不適切な設計がされている典型的な例となっていたのですが、実際、SI業界ではあのような品質のコードのシステムが今でも現役で多数稼動しているというだけでなく、現在でも新たに生み出されているというのは残念ながら紛れもない事実のようなのです。 確かに新人研修で「哺乳類を継承して犬クラスと
次世代のモックフレームワークであるJMockitの基本的な使い方 - 達人プログラマーを目指して
以前のモックフレームワークの技術的制約 今まで私が担当してきたプロジェクトにおいては、モックオブジェクトを使ったJUnitの単体試験はjMockとEasyMockのいずれかのフレームワークを利用して行ってきました。しかし、これらのフレームワークはJavaプラットフォームにおけるコード自動生成の考え方の変遷で説明したように動的プロキシーに基づいているため、以下のような制約がありました。 モック化する対象の型はインターフェースを実装しているか、継承可能なクラスであること モック化するメソッドはfinal、static、privateでないこと*1 モック化するロジックはコンストラクターの呼び出しではないこと モックオブジェクトをテスト対象クラスにDIかパラメーター経由で引き渡すことが可能であること モック化する場合はクラス全体をモック化する必要があること（getterやsetterなどは本物の
JavaをSEとEEに分類するのは今では無意味になってきている？ - 達人プログラマーを目指して
ご存知のとおり、かなり以前からJavaプラットフォームはJava SEとJava EEとに分かれています。Java EEはJava SEを含んだ拡張APIを含み、エンタープライズ開発向けのプラットフォームということで一般的にはなんとなく理解されていますが、よくよく調べてみると両者の境界線はかなりあいまいで、人によってさまざまな解釈の違いや混乱があるようです。 一応、Java SEとJava EEのJava DOCを調べてみると主なものとして以下のようなAPIが含まれていることがわかります。 プラットフォーム API Java SE 基本言語ライブラリー、通信ライブラリー、 GUI関連ライブラリー、JDBC、JNDI、RMI、Java IDL（CORBA）、JMX Java EE サーブレット、JSP、JSF、EJB、JPA、JMS、JTA、JCA Webサービス関連ライブラリー、Java
開発チームにアーキテクトがいないなと感じてしまうような、残念なコードスメルの例 - 達人プログラマーを目指して
まったく個人的なモチベーションの問題から、前回の最終更新から2年以上が経過してしまい、多くの読者のみなさんにはご心配をおかけいたしました。「プログラミングに関して調べたことや日々感じたことをメモとして残していきたいと思います。」というもともとの原点に立ち返って、あまり気負わずに、また今後も時々更新していけたらと思います。今までこのブログの主なテーマとして、JavaEEやSpringといったような、いわゆる業務開発で使われるような技術を中心としてきたわけですが、最近Springを使ったJavaの開発に（アーキテクトではなく）プログラマーとしてちょっと参加する機会があったので、その時気づいたこと、感じたことを書いてみたいと思います。 さて、皆さんはアーキテクチャやアーキテクトという言葉に対してはどのようなものをイメージするでしょうか。システムのセキュリティを確保するための方式であったり、大量の
Java総称型のワイルドカードを上手に使いこなすための勘所 - 達人プログラマーを目指して
Java5以降では総称型（generics）がJava言語に導入されています。総称型自体は、最近の静的な型付けのプログラミング言語で珍しいことではなく、現在の最新版では.NETのC#やVisual Basicにも導入されています。一般的には総称型をサポートするクラスライブラリを自分で正しく定義することは非常にスキルがいるが、事前に定義されたクラスを使うだけであれば、それほど難しくないとされています。しかし、Java言語の総称型は本エントリで説明するように特殊なところがあり、単に利用するだけでも他の言語に比べて遥かに難しいところがあるというのも事実です。特に総称型をパラメータ化する際に指定するワイルドカード型（List<? extends Serializable>など)の意味を正しく理解して使いこなすことは簡単なことではありません。その結果、昔のJDK1.4までのように型パラメーターのない
プログラミングと設計は本来切り離せないものなのでは - 達人プログラマーを目指して
最近はアーキテクトという役割で客先に常駐し、フレームワークの選定をしたり、事前に共通部品を設計したりする役割を担う仕事を引き受けることが結構あります。そこで運よくお客様のマネージャーがオブジェクト指向開発の経験が十分にある方だと、IDEなどの開発環境やインターネット接続環境を当然のように用意してくれるので最初から仕事がスムーズにできるのですが、そうでないとMS Officeしか入っていないロースペックのノートPCを渡されて、要件定義フェーズの期間中、フレームワークの設計をお願いしますとか、私としてはちょっと首をかしげてしまうような困ったことを言われてしまう場合があります。開発フェーズが始まる半年後まではコーディングは基本的に不要という考え方です。アプリケーションのアーキテクトという役割では少なくともコーディング規約を考えたり、ツールやフレームワークの選定をしたりする必要がありますし、プロジ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
