アーキテクトでしょうか？いいえ違います！

あまりにもアレだったんで曝してみる。

このブログ初の憂鬱ネタじゃないだろうか？

問題のコード(概ねこんな感じ)

import java.io.*;
import java.util.*;

public class Params implements java.io.Serializable {
  private java.util.Map params = new java.util.HashMap();
  Foo getFoo(){
    return new Foo();
  }
  void setFoo(Foo foo){
  }
  Bar getBar(){
    return (Bar)this.params.get("dummy");
  }
  void setBar(Bar bar){
    this.params.put("dummy",bar);
  }
}

このソースを見て本能的にマズイ！と思えない人は
アーキテクトと名乗らないでください！！

いやね、説明はしたんですよ。。
I：『SerializableでprivateのMapは良くないよ。だから、Serializable諦めるか、ちゃんとメンバで持とうよ。あと"dummy"って酷いから・・・』
HE:『いや、今ある実装を提携先に渡す為に実装を削っただけだから問題ない！（エヘン）』

？

いや、、、待て、、色々突っ込み所が有りすぎて困るが、とりあえず上等だ！黙って体育館の裏まで面かせ！！

ウチのアーキテクトの言葉である・・・

問題無い！じゃねーよ。問題しかねーよ

問題

大きい順に上げて行こう

技術は政治じゃ解決しない・・・

まずはココからでしょう。
技術的にマズい事は絶対に理屈捏ねるだけじゃ解決しないのだ。口だけ野郎が！

マズい物はマズいと認めてください。頼むから・・・

提携先に渡す

何の用途なのか、最早聞きませんでしたが
何の用途であってもダメでしょう！

サンプルとして出すのでも、開発用のスケルトンでも、、

というかスゲー恥ずかしいです。
会社ごとナメられそう・・・今ある実装ってのが更に救えないのですが・・・

実装を削っただけ

Serializableなクラスは明らかにデータコンテナです。
だからロジック実装があってはいけません。
（だからGetterにnewとかが残ってるのでしょう）
ロジック書きたいならSerializableは外しましょうよ。

これは既存のコードの問題で今回の問題とは本来関わりが無いのですがリファクタリング対象でしょうね。

メンバにしよう。ツールを使おう。

Setter / Getter 使うならMapで持つメリット無いでしょ？
eclipseとかで生成できるんだから素直にメンバに書こうね。

privateメンバーはSerialize対象にならない。

あくまでSetter / Getter に順ずる事になる。
だから例えば

  Bar getBaz(){
    if ( this.params.get("Flg") ){
      return (Baz)this.params.get("Flg");
    } else {
      return (Baz)this.params.get("Baz");
    }
  }

とかって書いちゃうと簡単にSerializeが崩壊するんだよ。
だから何でも入っちゃうMapとかを持っちゃうとバグり易いし追い難いんだ
勿論これはメンバーで持った場合でも起き得るけど
ちゃんとFlgにGetter / Setter があれば動くし格段に発見しやすい。
（でもコンテナに処理は・・・ってのがあくまで基本）

百歩譲って・・・

public class Params implements Serializable {
  public Map params = new HashMap<String,Serializable>();
}

どうしてもMapでやりたいなら、もうこれで良いじゃん

"dummy"って酷いです

そんだけ

まとめ

そんな訳で久しぶりに理不尽なやり取りだった。
まあ僕の腹が痛まないなら良いけどね・・・なんでもさ。

もしかしたら本人の目に触れるかも知れないが、、もういいや・・・