Elevate your software delivery from planning to production and beyond, with built-in AI, CI/CD, and a best-in-class Jira integration.

最近Groovyから遠ざかっていたため、勘を取り戻す練習も兼ねて、先日Javaプログラミング能力認定試験課題プログラムのリファクタリングレポート(その3) - 達人プログラマーを目指してでご報告したサーティファイJavaプログラミング認定試験のリファクタリング結果をGroovyに移植してみました。また、使い始めたばかりで良くは理解できていないのですが、ビルドもMavenからGradleに切り替えてみました。 現時点ではテストも不十分ですし、十分にGroovyらしいコードにも修正できていませんが、一応コードは以下に登録してあります。(ビルド方法は後述) リファクタリングGroovy版 一方、もともとのJavaのリファクタリング結果は以下にあります。 リファクタリングJava版 Javaからの基本的な修正手順 Java版のリファクタリング結果に対して、基本的には以下の手順で修正を加えました。
Java: The Good Partsの本のタイトルに触発されて、逆にJava言語の使いにくい部分をいくつかピックアップしてみました。Java EEなどの業務系のアプリケーションプログラマーの視点で書いていますので、別の立場ではここで指摘している事項が必ずしもBad Partではないという指摘もあるかもしれませんし、他にもいろいろなポイントがあると思いますが、とりあえず、私の独断で思いついたものを10個説明したいと思います。 1.標準APIのチェック例外が扱いにくい Java言語のチェック例外は本当にGood Partなのか? - 達人プログラマーを目指してでも取り上げましたが、Bad Partの第一番目として標準APIのチェック例外が扱いにくいという点を指摘させていただきたいと思います。チェック例外については、理屈上コンパイラーによって例外の処理をプログラマーに強制させることができるす
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く