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

2011年9月18日日曜日

iOS, Android, Windows Phoneのメモリ管理とかメッセージングの仕方を調べてみた

ぼちぼちTwitterにつぶやいていたらTogetterにまとめてくださった方がいらっしゃるので、せっかくなのでこちらでも紹介したいと思います。

http://togetter.com/li/189550 (githubみたいにembedできればいいのになーなんて><)

結構気合い入れて調べたのでおすすめです。

2009年12月19日土曜日

Java 使いの人向け ActionScript3 のクラス仕様まとめ

仕事の都合でJavaからActionScript3(FlexじゃなくてFlash 10みたいです)に乗り換えることになったので、クラスの仕様に親しむためまとめを作ってみました。


■参考文献
http://www.tom.sfc.keio.ac.jp/~fjedi/wiki/index.php?%A5%AF%A5%E9%A5%B9%BC%FE%A4%EA%A4%CE%BB%C5%CD%CD%28ActionScript3%29
こちらのWikiに完璧にまとまっていますので、ぶっちゃけこのWikiを見ればすべて解決すると思います。


■大原則
迷ったらJavaと同じ。
以下のJavaと違う点に掲載のない事項はすべてJavaと同じ。多重継承が無くてinterfaceが用意されている点など。


■Javaと違う点
  1. package宣言は.NETやC++のように{}で囲む必要がある。{}で囲んだ中はJavaとほぼ同じ。publicクラスが一つしか持てない等。
    package {
        //以下javaと同じ
        import flash.text.TextField;
        public class Hogehoge extends TextField { /*...*/ }
    }
  2. package{}の外側にファイルローカルな関数や変数やクラスを宣言できる。この領域はpackage{}の内側でインポートしたクラスやメソッドが使えない。別途インポートし直す必要がある。
    package {
        import flash.text.TextField;
        public class Hogehoge extends TextField { /*...*/ }
    }
    // 別途インポートが必要
    import flash.text.TextField;
    var abesi:TextField = new TextField();
  3. dynamicクラスがある。
  4. abstractクラスやabstractメソッドが無い。
  5. その他、native, synchronized, transientなどが無い。
  6. namespaceがある。(が、正直使い道がよく分からない)
  7. enum型はない。
  8. コンストラクタにもfunctionを付ける必要がある。
  9. コンストラクタは必ずpublicになる。アクセス制御修飾子を指定しないとpublicとして扱われる。
  10. オーバーロードが一切使用できない。コンストラクタもオーバーロードできない。
  11. オーバーライドの際には必ずoverride修飾子を付ける必要がある。
  12. プロパティのgetter/setterを作るために特別な仕様がある(get修飾子, set修飾子)

その他、クラス以外の違いとして、
  1. String型が参照渡しではなく値渡し(プリミティブ扱いなので)
  2. 関数の引数にデフォルト引数が利用できる(オーバーロードの代わりに使う)
    function abesi(a:String="abesi", b:String="hidebu") { /*...*/ }
    abesi(); //自動的にデフォルト引数が使用されるのでこういう呼び出しが可能
  3. 関数の可変長引数の指定の仕方が異なる
    //Javaでは
    public void abesi(String... args) { /*...*/ }
    //AS3では
    public function abesi(...args) { /*...*/ }


■サンプル
以上を踏まえて、練習がてらにプレイスホルダー付きテキストフィールドクラスを作ってみました。

Javaではコンストラクタのオーバーロードが必要になったところ、AS3ではデフォルト引数のおかげですっきり書けました。やっぱりデフォルト引数はいいですね。あと試しにtextColorプロパティのsetterをオーバーライドしてみたのですが、そのせいでthis.textColor = 0x999999とすると意図しないタイミングでdefaultTextColorが書き換わってしまいはまりました。super.textColorとしてスーパークラスのsetterを呼びだすようにして回避。getter/setterのオーバーライドは強力ですが上手く使わないと混乱を招く諸刃の剣になりそうです。

2009年11月23日月曜日

Mac OS Xには最初から/usr/share以下にmaven2やantが付いてくる

先日のScala Hackathon #1にて初めて気づいた驚愕の事実。なんとMac OS Xには最初からJavaの開発ツールが付いてきていたのでした。
akisute ~$ mvn --version
Maven version: 2.0.9
Java version: 1.6.0_15
OS name: "mac os x" version: "10.6.2" arch: "x86_64" Family: "mac"
akisute ~$ ant -version
Apache Ant version 1.7.0 compiled on July 20 2009
akisute ~$ which mvn
/usr/bin/mvn
akisute ~$ which ant
/usr/bin/ant
ちょっとmaven2のバージョンが古いですが、普通に使う分にはたぶん問題なさそうです。ちなみにこれらのツールは/usr/share以下に用意されています。
akisute ~$ cd /usr/share
akisute share$ ls
NotificationServer/ distcc_compilers info/ sandbox/
Ssh.bin doc/ java/ screen/
TargetConfigs/ emacs/ junit/ sdef/
aclocal/ enscript/ langid/ servermgrd/
aclocal-1.10/ examples/ libiodbc/ skel/
ant/ file/ libtool/ snmp/
apr-1/ ftpd/ locale/ statsCollector/
autoconf/ gdb/ man/ swig/
automake-1.10/ germantok/ maven@ tabset/
bakefile/ gprof.callg mecab/ tcsh/
bison/ gprof.flat misc/ terminfo/
caldavd/ groff/ mk/ texi2html/
calendar/ gtk-doc/ openmpi/ texinfo/
cracklib/ gutenprint/ openmpi-default-hostfile uucp/
cups/ heapdiff/ openmpi-mca-params.conf vim/
cvs/ hiutil/ openmpi-totalview.tcl xcode-select/
derby/ httpd/ podcastproducer/ zoneinfo/
dict/ icu/ ri@ zsh/
おお、他にもderbyとかありますね。TomcatやJettyのようなサーブレットコンテナがないので、そのまますぐにWebアプリ開発とはいきませんが、なかなか面白そうです。

・・・む、ひょっとしてこれ常識ですか? ><

2009年8月10日月曜日

何でもいいから作ってみようと思って作った結果がこれだよ!




製作期間二日。この程度の物に二日とか許されるのは小学生までよねー・・・orz
一応自機も動くしあたり判定もあるしゲームオーバーにもなるよ!すごいよcocos2d!



以下、全然関係ないけど設計のお話です。

(2009/08/30追記) 以下の内容に従って作ってみた結果がこちら:http://akisute.com/2009/08/blog-post_29.html
見ての通り大失敗してます。やっぱり継承して作った方がうまくいくっぽいです・・・


Javaの継承システムでは、サブクラスはスーパークラスのコンストラクタを引き継がない。また、暗黙的にスーパークラスのデフォルトコンストラクタを最初に呼びだすことになっている。だから、これはコンパイルが通らないし、
class Parent {
    private String name;
    public Parent(String name) {
        this.name = name;
    }
}

class Child extends Parent {
    int age;
    public Child(int age) {
        // デフォルトコンストラクタがないし、明示的にSuper(String)を呼んでいない
        this.age = age;
    }
}
これもコンパイルが通らない。
class Parent {
    private String name;
    public Parent(String name) {
        this.name = name;
    }
}

class Child extends Parent {
    int age;
    public Child(int age) {
        super("child");
        this.age = age;
    }
}

public static void main(String[] args) {
    // ChildにはSuperのコンストラクタが継承されないのでこれはできない
    Child child = new Child("akisute");
}
ところがObjective-Cの継承システムでは、サブクラスがスーパークラスのイニシャライザをすべて受け継いでしまう。なぜならイニシャライザも何の変哲もないタダのメソッドだから。だから、こんなコードが書けてしまう。
@interface Parent : NSObject {
    NSString *name;
}
@end

@interface Child : Parent {
    int age;
}
@end

@implementation Parent
    - (id)initWithName:(NSString *)aName
    {
       if (self = [super init])
       {
           name = aName;
       }
       return self;
    }
@end

@implementation Child
    - (id)initWithAge:(int)anAge
    {
        // Parentにはinitが無いが、NSObjectにはあるので
       if (self = [super init])
       {
           age = anAge;
       }
       return self;
    }
@end

int main (int argc, char const *argv[])
{
    NSAutoreleasePool * pool = [[NSAutoreleasePool alloc] init];
    // Childには無いinitWithNameが呼び出せてしまう
    Child *child = [[[Child alloc] initWithName:@"akisute"] autorelease];
    NSLog(@"@%", child);
    [pool release];
    return 0;
}
で、何が一体問題になるのかというと、この仕様のせい(おかげ?)で安易な継承が出来なくなっている。たとえば今回のcocos2dを使ったゲームでは、キャラは全部Spriteのサブクラスにしたかったんだけれども、そうするとSpriteクラスに最初から用意されているイニシャライザ(initWithFile:とかinitWithTexture:とか)が外に漏れてしまう。しかもこいつらを呼びだされると本来自分の作ったキャラクラスで呼びだしたかったイニシャライザが回避されて、任意の画像でへんちくりんなキャラを作られてしまう危険性がでてしまう。そこで、今回はこういうふうに継承ではなくてコンポジットを使ったコードにした。
@interface MSObject : NSObject {
    /** Sprite for this object. Can be changed to AtlasSprite for further performance. */
    Sprite *sprite;
    /** Hit box size */
    CGSize hitBoxSize;
}
後から考えたらこの方が正解だった。だって、こうしておけば外へ公開するAPIを変化させずに、中身のSpriteをよりパフォーマンスの良いAtlasSpriteに後からいくらでも差し替えられる!

2009年6月7日日曜日

java-ja #15 TDDとかペアプロとか

株式会社ドワンゴの本社にて開催された、java-jaの第15回勉強会に参加してまいりました。(ドワンゴさんありがとうございます!噂通りの社風が垣間見られておもしろかったです)
今回のテーマはTDDとペアプロ。TDDの権威である@t-wadaさん(http://twitter.com/t_wada)の講義+実際にTDD&ペアプロを体験する時間が設けられ、非常に充実した時間が過ごせました。

以下、Twitterにアップした感想を転載。


とにかく疲れる!そして慣れていないせいもあるがコードが進まない!普段の倍疲労して半分しかコードが進まないなら、明らかに生産性が下がっているように見える。でも違う、逆だ。こんなに生産的にコードが書けるとは思わなかった!

TDDを進めていくうちに、自分が意図しない考えや見落とし、typoなどの指摘が次々に飛び出した。書き上がったテストコードも普段自分が作っているものより綿密だ(もっとも普段はかなり手抜きなのだが)。TDDに反する進め方を指摘してストップすることもできた。

TDD自体はというと、テストケースが増えたり仕様が複雑化してきたりすると、途端に難易度が跳ね上がるな。一箇所直すと複数のテストがあっという間に真っ赤になる!新しくテストを作る判断とかも難しい、なによりテストを実行するのが面倒になったりする。jUnitMaxが素晴らしい理由を体感。

ペアプロの弱点は調べ物だな。明らかに調べ物をするときは個々人がググったほうが早い。だから熟練度が高くないとオーバーヘッドが大きくなってかえって非効率的。@yuruyoroさんには足引っ張って申し訳ない。スキルの差を埋める必要があるのも課題かなー、、、

個人的には一人でやる方が楽かな。人と話すのがへたくそ何だよなあ、、、いつもより疲れるのもそれが原因かも。ウォーターフォールがいけてないとはよく言うが、TDDやペアプロ自体にもたくさん課題があるのだなー、、、でも同じ課題満載なら、新しいやり方を開拓する方がいいよね、多分


TDDやペアプロは良いプラクティスですが、慣れないと実践は難しいですし、ウォーターフォールに代わる銀の弾丸でもなさそうです。そのことを実際に体で覚えることができたのが一番の収穫かな!

2009年5月4日月曜日

Objective-CではJavaのようにNullPointerExceptionが発生したりしない

そう、Objective-CにはNilPointerExceptionのようなものがないんです。
Javaでは
int main(String[] args) {
  String str = null;
  int length = str.length(); //NullPointerException

  // bar()がnullだとNullPointerException
  Object result = Foo.bar().baz().abesi().hidebu();
}
Objective-Cでは
int main(int argc, char** argv){
  NSString *str = nil;
  int length = [str length]; //何も起こらない。lengthにはデフォルト値0が入る

  // barがnilを返したら、後続のbaz, abesi, hidebuもnilを返す。
  id result = [[[[Foo bar] baz] abesi] hidebu];
}

同僚の方(http://twitter.com/ksk_matsuo/status/1682599075)よりこっそり教えていただきました。ありがとうございます!

なんと言ってもJava人にとっていちばん恐ろしいのがこのNullPointerExceptionなのですよ。だからオブジェクトのメソッドを呼び出すときはいつでもオブジェクトがnullだったらどうしようガクブルと思いながらプログラム書いてるわけです。それがいきなり「Objective-Cになったらぬるぽなんてありません安心です^^」なんて言われても安心できないなぁ><

2009年4月17日金曜日

第1回java-ja温泉に行ってきます

http://java-ja.yoshiori.org/index.php?%E7%AC%AC%E5%8D%81%E4%B8%89%E5%9B%9E

以下、やろうと思っていることリスト
  • 昔作ったGAEアプリを作り直し、Werkzeugなんか使ってみたい
  • iPhoneアプリを作成する、こないだ書いたPythonのツールを移植するだけ
  • Javaはインストールすらしていません