私たちのコードベースは、私のような古いプログラマーと新しいプログラマーであり、均一性のために行われた方法ですぐにそれを行うことを学びます。私たちはどこかから始めなければならないと考えて、私は自分自身にそれとしてデータホルダークラスをリファクタリングしました：

• セッターメソッドを削除し、すべてのフィールドを作成しましたfinal（final公理的には "良い"です）。結局のところ、セッターはコンストラクターでのみ使用されていたため、副作用はありませんでした。
• Builderクラスを導入しました

コンストラクター（そもそもリファクタリングを促したもの）が約3行のコードにわたるため、Builderクラスが必要でした。それは持っている多くのパラメータを。

運が良ければ、チームメイトが別のモジュールで作業していて、たまたまセッターが必要でした。なぜなら、必要な値がフローのさまざまなポイントで利用可能になったからです。したがって、コードは次のようになりました。

public void foo(Bar bar){
    //do stuff
    bar.setA(stuff);
    //do more stuff
    bar.setB(moreStuff);
}

セッターを取り除くことでフィールドが不変のままになることを可能にするため（以前に不変性についての不満を聞いたことがあります）、またビルダーはオブジェクトの作成をトランザクション可能にするため、代わりにビルダーを使用する必要があると主張しました。次の擬似コードをスケッチしました。

public void foo(Bar bar){
    try{
        bar.setA(a);
        //enter exception-throwing stuff
        bar.setB(b);
    }catch(){}
}

その例外が発生すると、barデータが破損しますが、ビルダーでは回避できます。

public Bar foo(){
        Builder builder=new Builder();
    try{
        builder.setA(a);
        //dangerous stuff;
        builder.setB(b);
        //more dangerous stuff
        builder.setC(c);
        return builder.build();
    }catch(){}
    return null;
}

私のチームメイトは、問題の例外は決して発生しないと反論しました。これはそのコードの特定の領域にとっては十分に公平ですが、ツリーのフォレストが欠落していると思います。

妥協案は、古いソリューションに戻すことでした。つまり、パラメーターのないコンストラクターを使用し、必要に応じてすべてをセッターで設定しました。理論的根拠は、このソリューションがKISSの原則に従っていることで、これは私の違反です。

私はこの会社には初めて（6か月未満）いますが、この会社を失ったことを完全に認識しています。私が持っている質問は：

• 「古い方法」の代わりにビルダーを使用する別の議論はありますか？
• 私が提案する変更は本当に価値がありますか？

でも本当に

• 何か新しいことに挑戦することを提唱する際に、そのような議論をより適切に提示するためのヒントはありますか？

どこかから始めなければならないと思って、データホルダークラスをリファクタリングすることにしました

これが間違っていたところです-コードベースに大きなアーキテクチャの変更を加えて、予想とは大きく異なるようにしました。あなたは同僚を驚かせました。サプライズは、パーティが関係する場合にのみ有効であり、サプライズの最小原理は金色です（パーティが関係する場合でも、きれいなパンツを着用することを知っています！）

この変更が価値があると思った場合、変更を示す擬似コードをスケッチして同僚（または少なくとも建築家に最も近い役割を持っている人）に提示し、彼らが何かをする前に考えたことを確認する方がはるかに良いでしょう。そのままで、あなたは不正になり、コードベース全体があなたが適切だと思うように遊ぶべきだと思った。チームのプレイヤーではなく、チームのプレイヤーです！

私はあなたに少し厳しいかもしれませんが、私は反対の場所にいました：コードをチェックして、「WTFがここで起こったのですか！」彼が「正しい方法」であるべきだと思うものに基づいたものの負荷。もう1つの大きな問題であるSCMの履歴もあるネジ。

運が良ければ、チームメイトが別のモジュールで作業していて、たまたまセッターが必要でした。なぜなら、必要な値がフローのさまざまなポイントで利用可能になったからです。

説明したように、コードにセッターが必要な理由はわかりません。私はおそらくユースケースについて十分に知りませんが、オブジェクトをインスタンス化する前にすべてのパラメーターがわかるまで待ってはどうですか？

別の方法として、状況にセッターが必要な場合：オブジェクトの準備ができた後にフィールドを変更しようとすると、セッターがアサーションエラー（プログラマーエラー）をスローするようにコードをフリーズする方法を提供します。

セッターを削除してfinalを使用することは、それを行うための「適切な」方法であり、不変性を強制することだと思いますが、実際に時間を費やすべきなのでしょうか？

一般的なヒント

古い=悪い、新しい=良い、私のやり方、あなたのやり方...この種の議論は建設的ではありません。

現在、オブジェクトの使用方法はいくつかの暗黙のルールに従います。これはコードの記述されていない仕様の一部であり、チームはコードの他の部分がコードを誤用するリスクはそれほどないと考えているかもしれません。ここでやりたいことは、Builderとコンパイル時のチェックでルールをより明確にすることです。

何らかの方法で、コードのリファクタリングは Broken Window理論にいます。問題が発生した場合は修正する（または後の「品質改善」会議にメモする）のが正しいと感じられるため、コードは常に快適に動作します。安全で清潔です。しかし、あなたとあなたのチームは、「十分な」ものについて同じ考えを持っていません。誠意を持って貢献しコードを改善する機会としてあなたが見ているものは、おそらく既存のチームとは異なって見られます。

ところで、あなたのチームは必ずしもinertia性、悪い習慣、教育の欠如に苦しんでいると想定されるべきではありません...あなたができる最悪のことは、それらを見せるためにそこにいるすべての知識のイメージを投影することですコーディング方法。たとえば、不変性は新しいものではありませんが、あなたの仲間はおそらくそれについて読んでいますが、この主題が人気になっているという理由だけでブログで、コードの変更に時間を費やすよう説得するには不十分です。

結局、既存のコードベースを改善する方法は無限にありますが、時間と費用がかかります。私はあなたのコードを見て、それを「古い」と呼んで、それについてひと目でわかるものを見つけることができました。たとえば、次の正式な仕様ではなく、十分に主張する、多分コメントやテスト、十分なコードカバレッジ、unoptimalアルゴリズム、あまりにも多くのメモリ使用量、それぞれの場合の「最高」の可能なデザインパターンを使用していない、など十分ではありません広告nauseam。しかし、私が提起するほとんどのポイントについては、あなたは思うでしょう：それは大丈夫です、私のコードは動作します、それにもっと時間を費やす必要はありません。

おそらく、あなたのチームは、あなたが提案するのは、収益が減少するポイントを過ぎていると思います。（例外を除いて）示す例によってバグの実際のインスタンスを見つけたとしても、おそらくそれを一度修正するだけで、コードをリファクタリングしたくないでしょう。

そこで問題は、についてですどのようにそれらがしていることを考えると、あなたの時間とエネルギーを費やす限ら？ソフトウェアには継続的に変更が加えられますが、一般的には、適切な引数を提供できるようになるまで、あなたのアイデアは負のスコアから始まります。たとえあなたが利益について正しいとしても、それは「素敵な日、ある日...」バスケットで終わるので、それだけでは十分な議論ではありません。

あなたの議論を提示するとき、あなたはいくつかの「健全性」チェックをしなければなりません：あなたはアイデアを売ろうとしているのですか、それともあなた自身ですか 他の誰かがこれをチームに提示したらどうなりますか？あなたは彼らの推論にいくつかの欠陥を見つけますか？一般的なベストプラクティスを適用しようとしていますか、それともコードの詳細を考慮しましたか？

そうすれば、チームの過去の「間違い」を修正しようとしているかのように表示されないことを確認できます。あなたがあなたのアイデアではないが、合理的にフィードバックを受け取ることができることを示すのに役立ちます。これを行うほど、あなたの提案がフォローされる機会が増えます。

チームでBuilderパターンの使用を促進するにはどうすればよいですか？

あなたはしません。

コンストラクタに3行のパラメータがある場合、大きすぎて複雑すぎます。それを修正するデザインパターンはありません。

あなたはそのデータが異なる時間に利用できていたクラスを持っている場合、それは2つの異なるオブジェクトであるべきか、あなたの消費者は、コンポーネントを集約しなければならない、その後、オブジェクトを構築します。彼らはそれをするのにビルダーを必要としません。

他の人とうまく働くことよりも、正しいことを重視しているようです。さらに悪いことに、あなたは自分がしていることは権力闘争であることを認識していますが、あなたの経験と権威に挑戦している人々に物事がどのように感じられるかを考えることに失敗します。

逆に。

他者との共同作業に焦点を当てます。提案やアイデアとしてあなたの考えを組み立てます。彼らにあなたのことを考えさせる質問をする前に、彼らに彼らのアイデアを通して話させてください。直接的な対立を避け、グループのやり方で物事に取り組むことは、グループを変えるために困難な戦いと戦うよりも生産的であることを外的に喜んで受け入れます。（ただし、物事を取り戻す。）あなたと一緒に仕事をすることを喜びにしてください。

これを一貫して行うと、競合が少なくなり、アイデアの多くが他の人に採用されるようになります。私たちは皆、完璧な論理的議論が他の人を驚かせ、その日に勝つという幻想に苦しんでいます。そして、それがそのように動作しない場合、我々はそれがすべきだと思う。

しかし、それは現実と直接対立しています。ほとんどの引数は、最初の論理ポイントが作成される前に失われます。論理的に言われている人々の間でさえ、心理学は理性に勝ります。人々を説得することは、適切に聞こえることに対する過去の心理的障壁を獲得することであり、完全な論理を持つことではありません。

「古い方法」の代わりにビルダーを使用する別の議論はありますか？

「新しいハンマーを手に入れると、すべてが釘のように見えます。」-これはあなたの質問を読んだときに私が考えたことです。

私があなたの同僚だったら、「コンストラクタでオブジェクト全体を初期化しないのはなぜですか？」それは結局のところ機能です。ビルダー（またはその他のデザイン）パターンを使用する理由

私が提案する変更は本当に価値がありますか？

その小さなコードスニペットから伝えるのは困難です。たぶんそれは-あなたとあなたの同僚がそれを評価する必要があります。

何か新しいことに挑戦することを提唱する際に、そのような議論をより適切に提示するためのヒントはありますか？

はい、議論する前に、このトピックについて詳しく学んでください。議論に入る前に、適切な議論と理論的根拠を身につけてください。

私は自分のスキルのために採用された状況にありました。私がコードを見るようになったとき、まあ..それは恐ろしいものでした。その後、それをクリーンアップしようとすると、そこにいた人は常に変更を抑制します。なぜなら、彼らには利点が見えないからです。あなたが説明しているように聞こえます。それは私がその地位を辞めることで終わり、今ではより良い実践をしている会社でより良く進化することができます。

チームの他のメンバーと一緒に役割を果たすべきだとは思わない。作業中のプロジェクトでチームメンバーが悪い慣行を使用しているのを見た場合、それをあなたが持っているように指摘する責任があります。そうでない場合、あなたは非常に貴重なリソースではありません。あなたが何度も何度も指摘しているにもかかわらず、誰も聞いていない場合は、管理者に交換または変更の仕事を依頼してください。悪い習慣に順応することを許可しないことが非常に重要です。

実際の質問へ

不変オブジェクトを使用する理由 何を扱っているか知っているからです。

セッターを介してホストを変更できるdb接続があり、それがどの接続であるかわからないとします。不変であることを知っています。

ただし、永続化から取得し、新しいデータで再永続化できるデータの構造があるとします。この構造は不変ではないことは理にかなっています。同じエンティティですが、値は変更される可能性があります。代わりに、不変の値オブジェクトを引数として使用します。

ただし、質問の焦点は、コンストラクターの依存関係を取り除くビルダーパターンです。私はこれに大きな脂肪NOを言います。インスタンスはすでに複雑になっています。非表示にしようとしないで、修正してください！

Tl; dr

クラスによっては、セッターの削除が正しい場合があります。ビルダーパターンは問題を解決するのではなく、単に隠すだけです。（カーペットが見えなくても、カーペットの下に汚れが残っています）

他のすべての答えは非常に便利ですが（私の場合よりも便利です）、まだ言及していないビルダーの特性があります。オブジェクトの作成をプロセスに変えることにより、複雑な論理的制約を強制できます。

たとえば、特定のフィールドを一緒に設定したり、特定の順序で設定したりすることができます。これらの決定に応じて、ターゲットオブジェクトの異なる実装を返すこともできます。

// business objects

interface CharRange {
   public char getCharacter();
   public int getFrom();
   public int getTo();
}

class MultiCharRange implements CharRange {
   final char ch;
   final int from;
   final int to;

   public char getCharacter() { return ch; }
   public int getFrom() { return from; }
   public int getTo() { return to; }
}

class SingleCharRange implements CharRange {
   final char ch;
   final int position;

   public char getCharacter() { return ch; }
   public int getFrom() { return position; }
   public int getTo() { return position; }
}

// builders

class Builder1 {
   public Builder2 character(char ch) {
      return new Builder2(ch);
   }
}

class Builder2 {
   final char ch;
   int from;
   int to;

   public Builder2 range(int from, int to) {
      if (from > to) throw new IllegalArgumentException("from > to");
      this.from = from;
      this.to = to;
      return this;
   }

   public Builder2 zeroStartRange(int to) {
      this.from = 0;
      this.to = to;
      return this;
   }

   public CharRange build() {
      if (from == to)
         return new SingleCharRange(ch,from);
      else 
         return new MultiCharRange(ch,from,to);
   }
}

これは意味のない節の多い例ですが、3つのプロパティすべてを示しています：文字が常に最初に設定され、範囲の制限が常に一緒に設定および検証され、ビルド時に実装を選択します。

これがどのように読みやすく信頼性の高いユーザーコードにつながるかは簡単にわかりますが、ご覧のとおり、多くのビルダーコード（そしてスニペットを短縮するためにコンストラクターを省略しました）にも欠点があります。そこで、次のような質問をして、トレードオフを計算します。

• 1つか2つの場所からのみオブジェクトをインスタンス化しますか？これは変わる可能性がありますか？
• 元のオブジェクトをより小さなオブジェクトの構成にリファクタリングすることで、これらの制約を強制する必要があるかもしれません。
• メソッドからメソッドへビルダーを渡すことになりますか？
• 代わりに静的なファクトリメソッドを使用できますか？
• これは外部APIの一部であり、可能な限りフールプルーフで滑らかにする必要がありますか？
• ビルダーがいれば、現在のバグのバックログのうち、どれくらい回避できたでしょうか？
• 追加のドキュメント作成はどれくらい節約できますか？

あなたの同僚は、トレードオフは有益ではないと単純に決定しました。できれば抽象的な原理に頼らずに、この解決策またはその解決策の実際的な意味に集中することなく、理由を率直に、正直に議論する必要があります。

このクラスは実際には複数のクラスであり、同じファイル/クラス定義にまとめられているようです。DTOの場合は、一度にインスタンス化して不変にすることができるはずです。1つのトランザクションですべてのフィールド/プロパティを使用しない場合、ほぼ確実に単一責任の原則に違反しています。それをより小さく、より凝集性のある不変のDTOクラスに分割すると役立つ場合があります。問題を明確に説明できるようになっていない場合は、Clean Codeを読むことを検討してください。

あなたが文字通りモブプログラミングをしているのでない限り、委員会によってこのレベルのコードを設計することはできないと思います（その種のチームにいるようには聞こえません）。最良の判断を下し、それが間違っていると判断した場合は、あごにそれを取ります。

ただし、コードの潜在的な問題をそのまま明確にできる限り、解決策が受け入れられない場合でも、解決策が必要であることを議論できます。その後、人々は代替手段を自由に提供できます。

「強い意見、弱い意見」は良い原則です-あなたはあなたが知っていることに基づいて自信を持って前進しますが、それに反するいくつかの新しい情報を見つけた場合、それは控えめで辞任し、正しい解決策が何であるかについて議論を入力してくださいあります。唯一の間違った答えは、悪化させるためにそれを残すことです。