@Kenjiro-U

Are you sure you want to delete the question?

If your question is resolved, you may close it.

Leaving a resolved question undeleted may help others!

We hope you find it useful!

勉強会で使える設計アンチパターン募集

はじめに

勉強会でアンチパターンとその改善を扱おうかと思いまして、
皆さんの周りのくそコードアンチパターンを教えていただきたいです。

サンプル

以下の例をご確認ください。

class A {
  private final B b;
  private final BState bState;

  A(B b, BState bState) { this.b = b; this.bState = bState; }

  void execute() {
    bState.setFailure(false);
    bState.setProcessing(true);
    b.execute();
  }
}

class BState {
  private boolean processing;
  private boolean failure;
  void setProcessing(boolean processing) {this.processing = processing;}
  void setFailure(boolean failure) {this.failure = failure;}
  boolean isProcessing() { return processing;}
  boolean isFailure() { return failure;}
}

interface B {
  void execute();
}

class BImpl implements B {
  private final BState state;
  BImpl(BState state) { this.state = state; }

  @Override
  public void execute() {
    try { /* 処理 */ }
    catch (Exception e) {
      state.setFailure(true);
    } finally {
      state.setProcessing(false);
    }
  }
}

上記の様に

  • コンパイルは通る
  • 動作的には正しい
  • 設計的に問題があり保守性等に問題がある
    というコード例を挙げていただければと思います。
0 likes

個人的に勉強会で扱うのであれば、「コンパイルは通るし一見すると正常に動くが、設計上の問題によって将来的な保守や拡張が難しくなる」という題材が最も盛り上がると思います。

例えば、提示されているコードのように複数のクラスが同じ状態オブジェクトを共有し、お互いの内部状態を直接変更する設計は非常に良いアンチパターンの題材です。処理自体は問題なく動作しますが、状態の変更箇所が分散するため、「いつ」「誰が」「どのような理由で」状態を変更したのかを追跡することが難しくなります。機能追加や例外処理の変更が入った際に予期しない不具合を生みやすく、密結合による保守性の低下を招きます。

また、勉強会では「God Object(神クラス)」も定番です。1つのクラスが認証、DBアクセス、メール送信、ログ出力、業務ロジックなどあらゆる責務を抱え込むため、修正のたびに影響範囲が広がり、結果として誰も安全に変更できないクラスになっていきます。さらに、DTOやEntityが単なるデータの入れ物となり、本来オブジェクトが持つべき振る舞いがServiceクラスへ集約されていく「貧血ドメインモデル(Anemic Domain Model)」も、Javaの業務システムでは頻繁に見かけるアンチパターンです。

その他にも、

  • booleanフラグの組み合わせで状態を表現する「フラグ地獄」
  • switch文やif文がシステム全体に散らばる「条件分岐の重複」
  • catch(Exception)で全てを握り潰す例外処理
  • staticユーティリティクラスへの過度な依存
  • マジックナンバーやハードコーディング
  • 巨大なServiceクラスやControllerクラス
  • public getter/setterを大量に公開してカプセル化を失う設計
  • Singletonへの過度な依存
  • N+1問題を引き起こすRepository実装

なども、「動くが長期的には辛くなる」という観点から非常に良い教材になります。アンチパターンは単なる「クソコード集」ではなく、「なぜその設計になってしまったのか」「当初は何を解決しようとしたのか」「どう改善すると責務が明確になり変更に強い設計になるのか」をセットで考えることで、より実践的な学びにつながります。

勉強会の題材としては、単純な文法ミスよりも「新人が書いてもベテランが急いでいても陥りやすい設計上の罠」を取り上げ、そのコードが数年後にどのような悲劇を生むのかというストーリー仕立てで紹介すると、参加者の共感を得やすく、非常に面白い内容になると思います。

0Like

Your answer might help someone💌