良いコード／悪いコードで学ぶ設計入門の書評｜低凝集・密結合が刺さり、分岐と名前の付け方を変えた

設計の基本をちゃんと学びたい。そう思って読んだのが『良いコード／悪いコードで学ぶ設計入門』です。

結論から言うと、動くコードは書けるけれど、変更しやすいコードの書き方を体系的に知りたい人に合う1冊です。悪い構造の例から入り、低凝集・条件分岐・密結合といった型ごとに直し方を見ていく作りです。

私にいちばん役に立ったのは、低凝集と密結合の章でした。読んでから、条件分岐の書き方と、名前の付け方を変えています。説明用のJavaのコードで見せながら書きます。

良いコード／悪いコードで学ぶ設計入門はどんな本か

書誌情報は技術評論社の初版の書籍ページと改訂新版の書籍ページによるものです。いま買うなら改訂新版です。私はKindleで読んだのですが、どちらの版だったかは覚えていません。この記事の章の名前は、初版の書籍ページの目次によるものです。

初版は全17章で、大きく3つのまとまりに分けられます（分け方は私の整理です）。

読んだきっかけ｜設計の基本を学びたかった

役に立ったところ｜低凝集と密結合

いちばん役に立ったのは、第5章「低凝集 ―バラバラになったモノたち―」と、第8章「密結合 ―絡まって解きほぐせない構造―」です。

低凝集：データとロジックが離れている

第5章には「staticメソッドの誤用」「初期化ロジックの分散」「共通処理クラス（Common・Util）」といった節があります。たとえば、注文のデータを持つクラスと、注文の計算をするUtilクラスが分かれている状態です（説明用の例）。

// 低凝集：データとロジックが別々の場所にある
public class OrderUtil {
    public static int calcTotal(Order order) { ... }
    public static boolean canCancel(Order order) { ... }
}

// Order はデータを持つだけ。どこで何が計算されるかは、Util を探さないと分からない
public class Order {
    public List<OrderItem> items;
    public OrderStatus status;
}

関係するデータとロジックを同じクラスにまとめると、注文について知りたいときは Order を見るだけで済みます。

// 凝集度が高い：関係するデータとロジックを同じクラスに置く
public class Order {
    private final List<OrderItem> items;
    private OrderStatus status;

    public Money total() { ... }
    public boolean canCancel() { ... }
}

密結合：別の役割が絡まっている

第8章には「密結合と責務」という節と、「共通化の罠」「継承」というコラムの見出しがあります。似ているからといって、役割の違う処理を1つのメソッドやクラスにまとめると、片方の仕様が変わったときに、もう片方まで巻き込んでしまいます。

読んでから変えたこと｜条件分岐を減らす・名前を目的で付ける

読んでから、2つのことを変えました。職場のコードは載せられないので、説明用のJavaのコードで見せます。

1. 条件分岐を減らした

第6章「条件分岐 ―迷宮化した分岐処理を解きほぐす技法―」には、「条件分岐のネストによる可読性低下」「switch文の重複」「interfaceの使いこなしが中級者への第一歩」といった節があります。ネストした if や、あちこちに同じ switch が出てくるコードは、読むのも直すのも大変です。

// ネストとswitchで分岐している
public int shippingFee(Member member, int price) {
    if (member != null) {
        if (price < 3000) {
            switch (member.rank()) {
                case GOLD:   return 0;
                case SILVER: return 300;
                default:     return 500;
            }
        }
        return 0;
    }
    return 500;
}

まず、早期returnで条件を先に片付けて、ネストをなくします。

// 早期returnで、ネストをなくす
public int shippingFee(Member member, int price) {
    if (member == null) return 500;
    if (price >= 3000) return 0;
    return member.rank().shippingFee();
}

会員ランクごとの違いは、ランクの側に持たせます。新しいランクが増えても、switch を探して回る必要がなくなります。ここではenumで書いていますが、ランクごとの処理が大きくなるなら、interface にして実装を分ける形にします。

// 会員ランクごとの違いは、ランク側に持たせる（switchの重複をなくす）
public enum Rank {
    GOLD(0), SILVER(300), REGULAR(500);

    private final int shippingFee;

    Rank(int shippingFee) {
        this.shippingFee = shippingFee;
    }

    public int shippingFee() {
        return shippingFee;
    }
}

interfaceと抽象クラスの使い分けはJavaの抽象クラスとはにまとめています。

2. 名前を目的で付けるようにした

第10章「名前設計 ―あるべき構造を見破る名前―」には「目的駆動名前設計」という節と、「Managerクラス」というコラムの見出しがあります。Manager・Util・Common のような名前は何でも入れられるので、気づくと1つのクラスに役割が集まってしまいます。

// 何でも入る名前
class ProductManager { ... }
class CommonUtil { ... }

// 目的で付けた名前（何をするためのものかで分ける）
class StockReservation { ... }   // 在庫を引き当てる
class PurchaseOrder { ... }      // 仕入れ先に発注する
class ShippingFee { ... }        // 送料を計算する

「何をするためのものか」で名前を付けると、そのクラスに入れてよいもの・いけないものが名前から決まります。名前を考えることが、そのままクラスの分け方を考えることになります。

今のレベル別の読み方

目次を見る限り、悪いコードの型ごとに章が分かれているので、気になる章から読み始められます。

向いている人・向いていない人

• 向いている人：設計の基本を体系的に学びたい人。動くけれど変更しにくいコードを、どう直せばいいか知りたい人
• 向いていない人：特定のフレームワークやライブラリの使い方を知りたい人。この本はクラスやメソッドの設計の本です

出版社の紹介でも、対象読者は「コードの設計スキルに興味がある人」「悪いコードと向き合い、改善したい人」とされています。

あわせて読みたい

• ドメイン駆動設計入門の書評：データとロジックをまとめる考え方を、業務の設計まで広げるなら
• Javaデザインパターン入門：条件分岐をなくすパターンをJavaで書くなら
• 単体テストの考え方/使い方の書評：設計を変えるときに、壊していないことを確かめるテスト

読んだ本はほかにも、トムの本棚に並べています。

よくある質問

Q. 初版と改訂新版、どちらを買えばいいですか？

いま買うなら改訂新版です。技術評論社の書籍ページでも、初版のページに新版が出ていると案内されています。この記事の章の名前は初版の目次なので、改訂新版では章の構成が変わっている可能性があります。

Q. Java以外の言語でも役に立ちますか？

初版の目次には「種類の異なる言語と本書のノウハウ」というコラムや、C#・Railsに触れたコラムの見出しがあり、ほかの言語で使うことも意識された作りです。

Q. 電子版はありますか？

改訂新版は電子版もあります（技術評論社の電子版ページがあります）。私もKindleで読みました。