ラベル Java の投稿を表示しています。すべての投稿を表示

2014年1月9日木曜日

Eclipseでメソッドをオーバーライドした際に、@inheritDocコメントを入れる

Eclipseにて

[環境設定] -> [Java] -> [Code Style] -> [Code Templates] -> [Comments] -> [Overriding methods]

こいつをEditして、下記の感じに編集

/**

* {@inheritDoc}

OKしてapply

下の方の、Automatically add comments for new methods and types

にチェックをいれればおしまい。

あとは、オーバーライドすると勝手に上記のコメントが挿入されるようになります。

2013年10月25日金曜日

Clean Code 2章のメモ

社内の輪講で使ったやつ

2章

意味のある名前

意図が明確な名前にする

これはだめ

public List<int[]> getThem() {
List<int[]> list1 = new ArrayList<int[]>();
for (int[] x : theList)
if( x[0] == 4 )
list1.add(x);
return list1;
}

ここがよくない
・暗黙さ

こんなかんじ

public<Cell> getFlaggedCells() {
List<Cell> flaggedCells = new ArrayList<Cell>();
for (Cell cell : gameBoard)
flaggedCells.add(cell);
return flaggedCells;
}

偽情報を避ける

似情報の例

・hp,aix,sco などの変数
unix由来？と錯覚する
・Listではないものに、hogeListとする
acoountsぐらいにしておく
・ごく一部のみが違う名前
・小文字のL,大文字のOなど

意味のある対比を行う

ノイズワード

・数字の連続（a1,a2...）
無情報です
source,destinationなど意味のあるものに

・意味のはっきりしない単語
Info? Data?
おなじです

・aとかtheのようなもの
明確な違いが生じるのであればOK
zorkがあるときに、theZorkはNG

発音可能な名前を使用する

・英単語として発音できるものにしよう

検索可能な名前を用いる

・1文字の名前は小さなメソッドのローカル変数でのみOK
・長い定数はあり
なるべく、enum、でいいんじゃね？

エンコーディングを避ける

・読めないものはよくない
・新たなことを覚えさせるのもだるい

ハンガリアン記法

・辞めよう

例）
long整数 lData
PhoneNumber phoneString; // やってしまう...

メンバープレフィックス

・m_など
そもそもなんで昔つかってたの？？

インターフェースと実装

・Iを前置、IHogeFactory
やめよう
・HogeFactoryImp or CHogeFactory
Cは具象のconcreteかな

メンタルマッピングを避ける

・i,j,kはループの中ぐらいなら可
・プロのプログラマは透明性を大事にする（賢い、のではない）

クラス名

・名詞あるいは名詞句をつけろ
Customer,WikiPage,Account,AddressParserCustomer
・Manager,Processor,Data,Info は避けるべき
・動詞を避けるべき

メソッド名

・postPayment,DeletePage,save などの動詞、動詞句
・Accessors,mutators,predicatesといった名前はメソッドが扱う値に付けるべき(get,set,isを前置しろ)
・コンストラクタがオーバーロードされている場合は、staticなファクトリメソッドを用意し、名前に引数を表現するものを含める

気取らない

１つのコンセプトには１つの単語
・複数のクラスで、fetch,retrieve,getを同じ意味で提供するとかやってはいけない
・controller,manager,driver なんかも紛らわしい
・整合性を持った語彙が大切

語呂合わせをしない

・addに、連結とコレクションの追記、２つの意味があるなどやってはいけない

解決領域の用語の使用

・すべての名前をいちいち業務用語か取り出すのは推奨しない
・プログラマーが分かる言葉（JobQueue,AccountVisitor）がよい

問題領域の用語の使用

・処理がプログラマちっくでないのであれば、業務側から用語を持ってきてもよい

意味のある文脈を加える

根拠のない文脈を与えない

2013年7月13日土曜日

struts2参考になるリンク集

本家

http://struts.apache.org/development/2.x/

日本語記事

マイナビ

実践サンプルで学ぶStruts 2 - 生まれ変わった定番フレームワークを徹底解説

Struts1系経験者のための「Struts2.1入門」

codezine

作りながら学ぶJavaアプリケーションフレームワーク

続 Struts 2入門

2013年6月11日火曜日

FreeMarkerのハッシュの要素にアクセスする（２）

前回「FTLのハッシュの要素にアクセスする」というのを書いたのですが、このときやりたかったことって、配列の「最後」にアクセスしたかったからなんですね。

でも、値直接指定じゃなくて、配列の最後を判定する構文がちゃんと用意されていたのでした。。。

マニュアルはちゃんと読みましょうというはなし。

例

[java]
<#assign foobar = ["hoge", "fuga", "piyo"]>

<#list foobar as str>
${str}
<#if str_has_next>さいごじゃ

[/java]

参考

http://freemarker.org/docs/ref_directive_list.html

2013年5月23日木曜日

FreeMarkerのハッシュの要素にアクセスする

T/Oなんですが。FTLのお話。

こんなハッシュがあったとして
[java]
<#assign hoge = [

{
"title":"fuga",
"id":"piyo"
}
] />
[/java]

ずらーっとね。で、特定要素にアクセスするときは、こんな感じで書けるっぽい。
[java]
<#list foo.hoge as bar>
　　　　<#if bar.id == "piyo">
　　　　ぴよぴよ
　　　　

[/java]
みたいな。

2013年2月16日土曜日

mavenプロジェクトでのjvmのバージョン指定してるトコ

mavenのサイトに書いてるけど。

http://maven.apache.org/plugins/maven-compiler-plugin/examples/set-compiler-source-and-target.html
maven-compiler-pluginのトコで指定だってさ。下の例はjdk1.4を指定してる様子。
[xml]

[...]

[...]

org.apache.maven.plugins
maven-compiler-plugin
3.0

1.4
1.4

[...]

[...]

[/xml]

2012年11月16日金曜日

【EffectiveJava輪講】5.ジェネリックス

※社内の輪講用メモ。まだ途中。

翻訳が、「ジェネリクス」ではなく、「ジェネリックス」なので、表記を合わせています。

p.n表記は、EffectiveJavaのページ番号です。

前史（ジェネリックス以前）

コレクションから読みだしたすべてのオブジェクトをキャストしていた。（挿入する型を間違えるとキャスト失敗）

現在（ジェネリックス時代）

個々のコレクションに許される型をコンパイラに伝え、コンパイラは自動的にキャストを挿入。誤った型を挿入しようとすると、コンパイル時に判明。

ジェネリックスを理解するために。変性の話。

（この辺参考URLから）

変位	意味	Javaでの例
共変	広い型から狭い型へ	A<P>はA<C>のスーパータイプ
反変	狭い型から広い型へ	A<P>はA<C>のサブタイプ
非変	型を変換できないこと	A<P>とA<C>の型に関係はない

Javaではすべてのジェネリック型は非変（ジェネリック型変数の変位指定はできない）。

不変であるということは、List<Object>のパラメータに、List<String>を渡すことができない。

No. 23 新たなコードで原型を使用しない

Javaのジェネリック対応は、過去バージョンとの互換性の維持が前提となっているため、犠牲にしている部分がある。

原型（Raw Type）が使用できること

変位指定ができない

要素型が不明な場合、原型を使用すると下記のように書いてしまうのはよくない(p.110)

[java]
static int numElementsInCommon(Set s1, Set s2) {
int result = 0;
for (Object o1 : s1)
if (s2.contains(o1))
result++;
return result;
}
[/java]

非境界ワイルドカード型で書きなおすと(p.111)

[java]
static int numElementsInCommon(Set s1, Set s2) {
int result = 0;
for (Object o1 : s1)
if (s2.contains(o1))
result++;
return result;
}
[/java]

非境界とは？

上限や下限がないこと。

原型を使用しない、の例外２つ

クラスリテラルでは原型を使用しないといけない（非境界ワイルドカード型だったらOK）

instanceofつかうとき
[java]
if ( o instanceof Set ) {
Set m = (Set) o; //Setでキャストする必要がある
}
[/java]

No. 24 無検査警告を取り除く

省略

No. 25 配列よりリストを選ぶ

なぜ配列よりリストを選ぶべきなのか？
配列は実行時の型安全は提供するが、コンパイル時の型安全は提供しない

配列の特徴

共変である

具象化されている

配列よりリストを選ぶ例(p.119)
[java]
import java.net.InterfaceAddress;
import java.util.ArrayList;
import java.util.List;

public class sample01 {

//元のコード
static E reduce(List list, Function f, E initVal) {
E[] snapshot = (E[]) list.toArray(); //警告
E result = initVal;
for(E e : snapshot)
result = f.apply(result, e);
return result;
}

//安全にする
static E reduce2(List list, Function f, E initVal) {
List snapshot;
synchronized(list) {
snapshot = new ArrayList(list);
}
E result = initVal;
for (E e : snapshot)
result = f.apply(result, e);
return result;
}

interface Function {
T apply (T arg1, T arg2);
}

}
[/java]

以下次回に持ち越し

No. 26 ジェネリック型を使用する

No. 27 ジェネリックメソッドを使用する

No. 28 APIの柔軟性向上のために、境界ワイルドカードを使用する

No. 29 型安全な異種コンテナを使用する

参考資料

EffectiveJava

http://d.hatena.ne.jp/ryoasai/20110325/1301078699

http://www.slideshare.net/nagise/jjug-ccc-2012-fall