SOLID をシンプルにする: クリーンなコード原則のための JavaScript ガイド

私が初めてソフトウェア開発の世界に飛び込み始めたとき、飛び交うあらゆる流行語や概念に圧倒されることがよくありました。特に困難に思えた概念の 1 つは、SOLID 原則でした。それは「真剣な」開発者だけが心配する必要があることのように感じました。しかし、コーディングに慣れてくると、これらの原則は派手なことではなく、数カ月後に髪の毛を抜きたくなくなるようなコードを書くことであることがわかりました。

それでは、JavaScript の SOLID 原則についての私の見解をここに示します。これは、JavaScript を始めるときにあればよかったと思う、実用的で実用的なガイドです。

1. 単一責任原則 (SRP): 1 つの仕事をうまくやり遂げる

それは何ですか？

単一責任の原則は、クラスが変更する理由は 1 つだけであるべきであり、つまり、クラスの仕事または責任は 1 つだけであるべきであると述べています。

現実のアナロジー

お気に入りのコーヒーショップのバリスタを思い浮かべてください。彼らの仕事はコーヒーを作ることです。突然、エスプレッソマシンを修理したり、ペストリーを提供したり、ゴミを出したりしなければならなくなったら、物事は混乱するでしょう。バリスタがコーヒーを作ることに集中するのと同じように、クラスでも 1 つのことをうまくこなすことに集中する必要があります。

JavaScript の例:

ユーザー認証、データ検証、データベース ストレージを処理する User クラスがあると想像してください。やりすぎだよ！これらの責任を個別のクラスに分割することで、コードの管理と保守が容易になります。

class UserAuthenticator {
  login(user) {
    // handle login
  }
}

class UserDataValidator {
  validate(user) {
    // validate user data
  }
}

class UserDatabase {
  save(user) {
    // save user to the database
  }
}

2. オープン/クローズド原則 (OCP): 拡張し、変更しない

それは何ですか？

オープン/クローズの原則では、ソフトウェア エンティティは拡張に対してはオープンであるが、変更に対してはクローズされるべきであると規定されています。言い換えれば、既存のコードを変更せずに新しい機能を追加できる必要があります。

現実のたとえ:

お気に入りのゲーム機を想像してみてください。新しいゲーム、コントローラー、アクセサリを追加できますが、そのために開いて再配線する必要はありません。同様に、コードのコア構造を変更せずに、コードに新しい機能を追加できる必要があります。

JavaScript の例:

面積を計算するメソッドを備えた Shape クラスがあるとします。三角形などの新しい形状を追加する必要がある場合、既存のクラスを変更する必要はありません。代わりに、拡張してください。

class Shape {
  area() {
    throw "Area method not implemented";
  }
}

class Rectangle extends Shape {
  constructor(width, height) {
    super();
    this.width = width;
    this.height = height;
  }

  area() {
    return this.width * this.height;
  }
}

class Circle extends Shape {
  constructor(radius) {
    super();
    this.radius = radius;
  }

  area() {
    return Math.PI * this.radius * this.radius;
  }
}

3. リスコフ置換原則 (LSP): 置換可能にしておく

それは何ですか？

リスコフ置換原則では、プログラムの正確さに影響を与えることなく、スーパークラスのオブジェクトをサブクラスのオブジェクトに置き換えることができる必要があると述べています。

現実のたとえ:

レンタカーを借りることを想像してみてください。セダンでも SUV でも、運転し、操縦し、停止するという車の基本的な機能を備えていることを期待します。レンタカーにまったく異なる制御セットが必要な場合は、大変なことになるでしょう。同様に、サブクラスは、親クラスによって設定された期待を裏切らない方法で動作する必要があります。

JavaScript の例:

Bird クラスとそれを拡張した Penguin クラスがある場合、ペンギンはたとえ飛べなくても Bird のように動作するはずです。まだ歩き、食事をし、おそらく泳ぐこともできるはずです。

class Bird {
  move() {
    console.log("Flies in the sky");
  }
}

class Penguin extends Bird {
  move() {
    console.log("Swims in the water");
  }
}

const myBird = new Bird();
const myPenguin = new Penguin();

myBird.move(); // Flies in the sky
myPenguin.move(); // Swims in the water

4. インターフェース分離原則 (ISP): オーダーメイドのインターフェース

それは何ですか？

インターフェイス分離原則は、クライアントが使用しないインターフェイスの実装を強制されるべきではないことを示唆しています。大きなインターフェイスを 1 つ持つ代わりに、より小さく、より具体的なインターフェイスを作成する必要があります。

現実のたとえ:

シェフがウェイター、バーテンダー、食器洗い機を兼任するレストランを想像してみてください。それは圧倒的で非効率的です！代わりに、各役割に固有のタスクを持たせる必要があります。同様に、インターフェースも特化され、焦点が絞られている必要があります。

JavaScript の例:

buildHouse、paintHouse、designHouse などのメソッドを含む Worker インターフェイスがある場合、家をペイントするだけの Worker は他のすべてのメソッドを実装する必要はありません。それをより小さなインターフェースに分割します。

class Builder {
  build() {
    console.log("Building house...");
  }
}

class Painter {
  paint() {
    console.log("Painting house...");
  }
}

class Designer {
  design() {
    console.log("Designing house...");
  }
}

5. 依存性反転原則 (DIP): 抽象化に依存する

それは何ですか？

依存関係逆転の原則では、高レベルのモジュールが低レベルのモジュールに依存すべきではないと述べています。どちらも抽象化に依存する必要があります。

Real-Life Analogy:

Think about how you plug your phone charger into a wall socket. You don’t need to know the details of the electrical wiring inside the walls—all you need is the interface (the socket) to power your device. Similarly, your code should depend on abstractions (interfaces), not concrete implementations.

Example in JavaScript:

If you have a LightBulb class that directly controls a Switch class, you’re creating a tight coupling. Instead, both should depend on an interface like PowerSource.

class LightBulb {
  turnOn(powerSource) {
    powerSource.provideElectricity();
    console.log("Light is on");
  }
}

class Switch {
  constructor(powerSource) {
    this.powerSource = powerSource;
  }

  operate() {
    this.powerSource.togglePower();
  }
}

class PowerSource {
  provideElectricity() {
    console.log("Providing electricity");
  }

  togglePower() {
    console.log("Toggling power");
  }
}

Conclusion

Mastering the SOLID principles is like learning to cook with a set of proven recipes. Once you understand them, you can whip up code that’s not just functional but elegant and easy to maintain. So next time you find yourself in a coding conundrum, remember: there’s a principle for that!

Happy coding! ?

以上がSOLID をシンプルにする: クリーンなコード原則のための JavaScript ガイドの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。