ボク、if文。わるいモンスターじゃないよ！ - 都元ダイスケ IT-PRESS
id:aroundthedistance に召還されたぜ。 http://d.hatena.ne.jp/aroundthedistance/20100727/1280227851 …その昔なー。Seasar Conferenceで「あなたのコードからnewとifが消えます、魔法のDI」みたいなセッションをした。今思い出して「釣りすぎたぜサーセン」という気分になったことをまず懺悔しておく。 この doBusinessん中のif〜else ifをなんとかしたい。 …（中略）… ちょっとすっきりした。けどまだifが残ってるよね。 ポリモーフィズムの例をもうちっと実用的に書いてみた。 - 都元ダイスケ IT-PRESS どんだけif文悪者なんだ。そこまで嫌ならば、一度もif文を書かずにコードを書けばいい。無理だがなｗ と自嘲。 if文に限らず、問題になるのは濫用なのだ。"ある知識"がトッ散らかって
インスタンスを抽象的に扱う - 都元ダイスケ IT-PRESS
まず「抽象的」という言葉が難しいのかな。俺も最初の頃、一体何なのかわからなかった。プログラムに全く縁もゆかりも無い相方に、オブジェクト指向の話をすこしだけ聞かせたことがあって、「抽象的って、要は大ざっぱってこと？」と問われた。なるほど、良い表現だ。 「Android携帯HT-03A」というオブジェクトがあったとする。それを大ざっぱに扱う（いや、別に物理的に雑に扱う訳ではなく）とはどういうことか。結論を言えば、「文脈上、細かい事を気にしなくて良い場合は、細かい事を記述しないこと」だ。 Android携帯として扱う → HT-03Aではなく、DesireやNexusOneで良い場合は、HT-03Aである、という限定をしない 携帯電話として扱う → Android携帯ではなく、ガラケーでも良い場合は、そういう限定をしない 電子機器として扱う → そもそも携帯の話じゃなくて、電子機器の話という文脈
難解なSerializableという仕様について俺が知っていること、というか俺の理解 - 都元ダイスケ IT-PRESS
java.io.Serializable …、ある程度Javaに触れて来た人は必ず見たことがあるインターフェイスだと思う。私も何度も見てきたし、必要に迫られて自分の作ったクラスにSerializableをつけたこともある。しかし、こいつは一体何なのか？ 継承の便利さ 僕らがまだJava初心者だった頃。継承というメカニズムに助けられながら育って来た。簡単に言えば、HttpServletクラスを継承しさえすれば、自分の作ったクラスがサーブレットとして認識されるのだ。また、abstractメソッドなどという便利な機能もあり、継承にあたって実装しなければいけないメソッドは確実に指示され、言われた通りにそのメソッドを実装すれば良い。 StrutsのActionも然り。そう、多くの場合は「継承さえすれば、望む物がだいたい出来上がる」というのがJavaの世界だと思っていた。 だが、世の中そんなに甘くない
堅牢なコーディングルールを策定する方法(1) - 都元ダイスケ IT-PRESS
「ある処理をするコードを書く」というのは「ある出来事を文章に表現する」のと似ていると思っている。 まず表現に使う言語は様々であり、使用人口の大小はあれど、基本的に優劣はない。言語が同じだったとしても、十人十色の表現をし、全く同じ出来事を表現したものであっても、複数人が全く同じ文章を作る可能性は限りなく小さい。同じ人が表現するんであっても、今と昔で「全く同じ文章」を書くとは限らない。むしろ微妙に差異があるのが普通だ。 そんな「コーディング」に一貫性を持たせるのがコーディングルールだ。インデントはスペース4つだとか、braceの位置はどうだとか。複数人で小説を執筆する*1場合は、「ですます調に統一しよう」とか色々な取り決めをすると思う。このあたりの一貫性がないと、非常に読みにくい小説が出来上がるだろう。 とまぁ、ルールってのは、複数人間の意識合わせのために*2存在する。例えば法律もそうだ。そし
「仕様」と「実装の詳細」(2) - 都元ダイスケ IT-PRESS
繰り返す。Fooクラスを利用するMainクラスを書く時、XはFooの「仕様」に依存すべきであり、Fooの「実装の詳細」に依存すべきではない。 public class Foo { public String bar; public Foo(String bar) { this.bar = bar; } public String getBar() { return bar; } } public class Main { public static void main(String[] args) { Foo foo = new Foo("hoge"); System.out.println(foo.bar); // (1) System.out.println(foo.getBar()); // (2) } } 上記のクラスはbarフィールドがpublicである。しかしFooのインターフ
仕様（インターフェイス）と実装の詳細 (1) - 都元ダイスケ IT-PRESS
APIの公開/非公開が意識できるようになると共に、「仕様（インターフェイス）」と「実装の詳細」を意識できるようになるとよい。 このクラスの公開APIはどれか、非公開APIはどれか このクラスの仕様（インターフェイス）はどれか、実装の詳細はどれか という2つの角度でクラスをとらえる。前者については昨日のエントリでも示した通り、可視性がpublic,protectedなものが公開APIであり、その他は非公開APIである。機械的に判断できますね。では後者についてはどう判断すればいいか？ 注：下の例で「このクラスのインターフェイスは？」と聞かれると単純に「Baz」と答えるかもしれない。がここで言いたいのは「Bazを介したFooのインターフェイス」ではなく「Foo自身が純粋に外部に公開する仕様としてのインターフェイス」のこと。インターフェイスとは何か？についてはinterfaceについて本気出して考
DevLOVE DB勉強会「DBも、進化せよ。」 - 都元ダイスケ IT-PRESS
で、話してきた。楽しかったーーー。 めちゃめちゃ疲れているけど、脳内麻薬が出ているぽいので、ブログくらいは書けそうだ。ブログを書くまでが勉強会ですよ、と言った手前、書かないわけにはいかないぜっ。 まぁ、セッションに関しては自分が話したので反省点のみ。緊張しすぎ俺ｗ もっと緊張せず、自然体で話せるようになりたいもんであります。 セッション時間の方は見積もりバッチリ。ほぼジャストの時間で終了しました。俺++ 今回は、事前に id:papanda と飲んだ時にDevLOVEの一つのポイント「明日から実践できること」というテーマをもらっていた。みんな色々な現場に属していると思うが、明日からいきなり「Jiemamy導入しましょう！」ったって難しいですよね。理解もまだまだ得られていないと思う。（理解をいただく為に、コツコツと巡業しますｗ） そこで、Jiemamyのベースとなっている考え方を基に、いくつ
Throwableについて本気出して考えてみた 2nd Season - 都元ダイスケ IT-PRESS
1st Seasonはこちら。Throwableについて本気出して考えてみた - 都元ダイスケ IT-PRESS 以前は、何かをスローする状況を3つに分けてそれに合った設計をした例外を投げましょう、という考え方を示しました。 callerのバグ: RTE calleeのバグ: Error どちらでもない: Exception (非RTE) まぁ詳しくはSeason1の方で。 Seasar2はRuntimeExceptionですね。2004年ぐらいからのフレームワークはRTEをスローしていると思いますよって、ひがさんから情報。 チェックされる例外とチェックされない例外について - じゅんいち☆かとうの技術日誌 ただ、上記のような考え方もあるのも事実。実際.NETやRuby, Python, 新鋭のScala等もcatchを強制する例外というものが言語仕様的に存在しません*1。逆に、チェック例
Apache commonsが便利な件（commons-configuration編） - 都元ダイスケ IT-PRESS
久々のシリーズ。 今回はcommons-configuration。設定ファイル、ってありますよね。Javaだとproperties、Windosだとiniファイルが使われる事が多い。複雑なものだとXMLで書いたりする。 さて、そんなファイルの読み込み・書き出しってどうしますか。まさかFileInputStreamで自前で読み出すとか、しないですよね。コメント行の処理等、やらなきゃいけないことは結構あります。まぁ、propファイルだったらPropertiesクラスで読み書きできますが、それでも、そうそう便利には出来ていません。 XMLファイルだったりすると、DOM組んで読み書きしますかね。これも結構大仕事。 という時に使うのがcommons-configurationのようです。まぁ、能書きよりコードですかね。 propertiesファイルの場合 foo = hoge foo.bar =
Throwableについて本気出して考えてみた - 都元ダイスケ IT-PRESS
Throwable、Exception、RuntimeException(RTE)、Errorあたりを整理しながら、色々考えてみた。私見に基づくので、間違っているかもしれないけれど、自分としては頭が整理できたかな、と感じたので晒してみる。異論があったらコメントください。 まず、一番基礎的なところで、継承関係の整理から。こんなツリーになっています。 Throwable Error Exception RuntimeException そして、本稿での用語の定義。caller＝呼出す側のコード callee＝呼出される側（throwする側）のコードとします。 Throwable Throwableは「throw文に指定できる何か」という意味ですね。 Instances of two subclasses, Error and Exception, are conventionally used
オブジェクト指向のプログラムに込める「意図」 - 都元ダイスケ IT-PRESS
その昔、プログラムを覚えたての頃、プログラムってのは単に「処理」を記述するものだと考えていた。処理を1ステップごとに記述し、場合によってはサブルーチンに切り出し、再利用する。 今振り返ると、オブジェクト指向を覚え始めてしばらくして、その意識は変わっていた。当然「処理」を落とし込まなければプログラムは動かない。だから「処理」はプログラムに込める。ただ、オブジェクト指向言語を使うと、これに加えて「意図」を落とし込むことができる。 オブジェクト指向を学び始めた当初、Javaのインターフェイスの存在意義がわからなかった。プログラムは「処理」を記述するものだという視点で見ると、インターフェイスには「処理」を書くことができない。インターフェイスだけでは何も起こらないからだった。 さらに、IDEを使ってコードを追っていると、途中でインターフェイスのソースを開くことになり、「なんだよ、中で何やってっかわか
敢えて規約を破るケース（Checkstyleの警告抑制） - 都元ダイスケ IT-PRESS
先日の日経ソフトウエア記事で、「規約は大事だが、可読性や保守性を高めるためにあえて例外的に規約を破るケースもある」ということを説明しました。 しかし、Checkstyleは情け容赦なく、違反を摘発します。 数が少ないうちは良いのですが、多くなってくると「無視すると決めた警告」に「大事な警告」が埋もれて、気づくべき違反に気づかなくなってきます。 そこで、checkstye.xml を少し編集してみましょう。TreeWalkerモジュールの子にFileContentsHolderモジュールを追加します。 … <module name="Checker"> <property name="severity" value="warning"/> <module name="TreeWalker"> <!-- 追加ここから… --> <module name="FileContentsHolder"
エンジニアとしての歩き方 - 都元ダイスケ IT-PRESS
これから書くことは決して「これをしなければいけない」とか「他に手段はない」なんてコトを主張したいのではない。色んな道があるはずだぁ。その中の一つの事例として、自分がやってきたことをフレームワーク化し、色々挙げてみようと思う。 当然、俺の主観が入りまくっているので、突っ込みどころは満載だろうなｗ そもそも「エンジニア」って何？ｗ その辺り、はてブ界隈のミナサマにおかれましてはお手柔らかに願いたいｗｗ さて、いきなりどこかの技術系カンファレンスで1時間喋っちゃえ、とか突然は無理なのは分かる。何を話せばいいのやら、どこに喋るチャンスがあるのやらだ。しかし、そういう所で喋るような自分を将来のビジョンとして持っている人は、以下に挙げることを小さなことからコツコツと実践してみるといいかもしれない。という意図で書いていく。 何事にも興味を持とう 興味は勉強の原動力。興味のない勉強は苦痛でしかない。ここが
継承とコンポジット - 都元ダイスケ IT-PRESS
id:happy_ryoに「わかんねーんだよ、説明してみろゴルァ」されたので、書いてみる。 前書き*1 とりあえず、本日のエントリのキモを最初に。「オブジェクト指向は、隠す技術である」（俺談ｗ）ということを意識して読んで見てください。隠すとは何か？ 公開しすぎない事。分かりやすく言えば、publicをprivateに変える事。これが「隠す」。 んじゃあ、隠すと何が良いのか。あるクラスから、見えるもの（＝操作できる可能性の範囲(scope)）が狭ければ狭いほど出来る事のバリエーションが減るから、プログラムは単純になる。つまり、隠すと複雑性(complexity)が下がる*2。 要件を満たした上で、いかに型（class, interface, etc.）やメンバ（field, method）の可視性を落とすか。可能な限り可視性を下げ、プログラムを単純化し、メンテナンス性を上げるにはどうしたらい
都元ダイスケ IT-PRESS
都元ダイスケ（当時34）は、クラスメソッド株式会社に転職しました。 こんだけJavaJavaしてた都元が、なんとAWSエンジニアになっております。世の中どうなるかわからんですね〜。まぁとは言え、ちょいちょいJava触ってますが。 そんなわけで、今後共よろしくお願いします！ って1年以上前の話やけどな。 「第一回チキチキjava-ja ymsr送別会」に行ってきた。 ちょっと湿っぽくなった瞬間もあったけど、笑いの絶えない良い会だった。 あいつは絶対準備して待ってる。 というわけで、その時が来たら、「第一回チキチキjava-ja ymsrによる歓迎会」に参加しようと思う。 しばらく待ってろ。 ごぶさたです。都元です。 日経ソフトウエア2012年8月号が昨日発売となりました。都元が特別付録の文庫サイズ別冊「Eclipse逆引きポケット事典」に寄稿しました。この原稿は、息子誕生の混乱のさなかに脱稿
例えば、if〜instanceofを避ける(1) - 都元ダイスケ IT-PRESS
先日の地豆の開発チャットでの話題をまとめておく。 Javaにおいて、気をつけて使わないとオブジェクト指向の世界を大きく壊してしまう可能性のある危険ワードはstaticとinstanceofだと思っている。staticについては、継承とコンポジットで少しだけ触れた通り。今日はinstanceofについて。 先日、オブジェクト指向は「隠す」技術だと言ったが、今日は「まとめる」技術だと言ってみる。 class A extends X class B extends X だったとして、何も考えずにこんなコードを書いたとする。 X foo = ...; if (foo instanceof A) { // class A用の処理(a) } else if (foo instanceof B) { // class B用の処理(b) } 見た感じ思うのはこんなこと。とても危険な臭いがするコードだ。 X
interfaceについて本気出して考えてみた - 都元ダイスケ IT-PRESS
本気出す第二弾。 オブジェクト指向を良く知らなかった頃*1、Javaの勉強を始めると、class, field, method, interface などのオブジェクト指向的な概念を覚えていくことになります。 その中で、一番「よくわからんけど、まぁそんなものがあるのね。しっかし、何のためにあるんだか全く分からない存在だな…。」という印象を受けるであろう、というか受けたモノは interface だった。 「プログラミング」＝「処理手順を書く」という認識で interface を見ると、全く存在価値が感じられないんだな。だって「処理手順書けない」んだもん。それなら別にわざわざ interface を implements とかしないで、処理手順を記述したclassの方の型で扱えばいいじゃん、と。 そんなこんなが、紆余曲折を経て、なんか interface を使ったコードを書いている。かといっ
バグ発生時に投げるべき例外 - 都元ダイスケ IT-PRESS
「メソッドを呼ぶ前提条件が間違っている（ユーザによるミス）」時の例外は、IllegalStateExceptionですよね。そして「引数が間違ってる（ユーザミス）」時はIllegalArgumentException。 しかし「バグが発生した（API提供側のミス）」時に投げるべき例外って、何がいいんでしょう？ 例えば「ここには絶対到達しない、ホントは」って場所に書いておくもの。 Effective Java 第2版 (The Java Series)だと、そういったポイントでは AssertionError を投げていますが、Errorを投げるって邪悪じゃねーかなぁ…ｗｗ しかも、AssertionError って assert文の評価失敗の時に投げられるものですよね。VMの起動引数に -ea が付いていないときは、むしろ「投げちゃいけないモノ」なんじゃないかな、と…。 さてさて…。単純に
Apache commonsが便利な件（commons-collections編-2） - 都元ダイスケ IT-PRESS
http://d.hatena.ne.jp/daisuke-m/20080702/1214982943 前回に引き続きcommons-collections。 Java Collection Framework(JCF)では、大きく分けてCollectionとMapの2系統の概念が定義されています。そして、前回はこれらに加えて Bag, Buffer などの追加された概念を説明しました。それぞれの代表的なタイプを整理したものが以下*1。 Collection List ArrayList ArrayStack (*) 実装はArrayStack。特筆事項なし。 LinkedList Stack Set EnumSet HashSet TreeSet Queue PriorityQueue Bag (*) 実装はHashBag, TreeBag。特筆事項なし。 Buffer (*) 実装はA
Apache commonsが便利な件（commons-io編） - 都元ダイスケ IT-PRESS
http://d.hatena.ne.jp/daisuke-m/20080702/1214982943 今回はcommons-io。 commons-io は、入出力まわりの便利クラスを提供してます。commons-langはjava.langの補強でしたが、こちらはjava.ioパッケージの補強、というスタンスです。 IOUtils closeQuietly こんなコード良く書きますよね。 InputStream is = null; try { is = ...; // ... } catch (IOException e) { // ... } finally { if(is != null) { try { is.close(); } catch (IOException e) { // ignore } } } だーーー、サンプルコード書いててウザかったｗ そのくらいウザいじゃな
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
