はじめに

Flutterを網羅的に学習するにあたってRoadmapを使って学習を進めることにしました。

この記事では、Flutter初学者やこれからFlutterを学習し始める方に向けて、SOLID原則についてまとめています。

RoadmapはFlutterだけでなく、他の言語やスキルのロードマップも提供されており、何から学習して良いか分からないと悩んでいる方にとって有用なサイトになっています。
ぜひRoadmapを利用して学習してみてください。

Roadmapとは

簡潔に言えば、Roadmap.shは学習者にとってのガイドブックであり、学習の方向性を提供する学習ロードマップサイトです。

初心者から上級者まで、ステップバイステップでスキルを習得するための情報が提供されています。

学習の進め方が分かりやすく示されているだけでなく、個々の項目に参考資料やリソースへのリンクも提供されているので、学習者は目標を設定し、自分自身のペースで学習を進めることができます。

SOLID Principles

FlutterロードマップSOLID Principlesでは以下の3つのサイトが紹介されています。興味のある方はぜひお読みください。

S.O.L.I.D Principles: https://www.youtube.com/watch?v=fvNTJang7l4
Overview of S.O.L.I.D Principles In Dart: https://medium.flutterdevs.com/s-o-l-i-d-principles-in-dart-e6c0c8d1f8f1
The S.O.L.I.D Principles in Pictures: https://medium.com/backticks-tildes/the-s-o-l-i-d-principles-in-pictures-b34ce2f1e898

SOLID原則とは

SOLID原則とは、オブジェクト指向プログラミングにおける5つの基本的な設計原則の頭文字を取ったもので、ソフトウェアの設計をより堅牢で保守性の高いものにするためのガイドラインです。

単一責任の原則 (Single Responsibility Principle - SRP)

コンポーネント(クラスや関数)が保持する責務（役割）は1つであるべきという原則です。複数の役割を持つクラスでは複数の利用者の要件を同時に満たせなくなるケースが発生します。

責任は、責任の適用範囲とセットで定義されなければなりません。

以下のUserクラスは複数の責務を持つクラスです。複数の責務がある場合、責務が密接に関連しているため、1つの責務を変更すると、他の責務にも影響が及ぶ可能性があります。

単一原則に違反している例

class User {
  // ユーザ情報関連の責務
  getUserName() {
    // ユーザ名を取得する処理
  }
  getEmail() {
    // メールアドレスを取得する処理
  }

  // 認証関連の責務
  login() {
    // ログイン処理
  }
  logout() {
    // ログアウト処理
  }

  // 支払い関連の責務
  makePayment() {
    // 支払い処理
  }
}

上記のクラスはユーザ情報、認証、支払い関連の3つの責務を持っています。しかし、SRPに従うと、クラスが担う責務はたった一つに限定すべきです。責務を一つに限定することで、バグが発生した際に、不正な動作がどこのクラス、またはメソッドで発生したのかを分かりやすくします。

単一原則を遵守している例

class UserProfile {
  getUserName() {
    // ユーザ名を取得する処理
  }

  getEmail() {
    // メールアドレスを取得する処理
  }
}

class Auth {
  login() {
    // ログイン処理
  }

  logout() {
    // ログアウト処理
  }
}

class UserPayment {
  makePayment() {
    // 支払い処理
  }
}

有名なソフトウェア原則に、DRY原則があります。
DRYとはDon't Repeat Yourself の略で、直訳すると「繰り返しを避けろ」という意味です。

ここで注意して欲しいのが、DRYにすべきは、それぞれの概念単位ということです。

同じようなロジック、似ているロジックであっても、概念が違えばDRYにすべきではないのです。

例えば、上記のコードでmakePaymentメソッドとgetEmailメソッドの処理内容が酷似していたとします。その場合でも、それぞれ責務が違えば、クラスは分けなければなりません。

このようにクラスやメソッドに持たせる責務を単一にすることによって、コードは理解しやすく、保守性が向上するのです。

単一責任の原則 Single Responsibility Principle - SRPについてもっと詳しく知りたい方はこちらにわかりやすい記事があったので、是非読んでみてください。

開放/閉鎖の原則 (Open/Closed Principle - OCP)

ソフトウェアの構成要素は拡張に対して開いていて、修正に対して閉じていなければならないという原則です。簡単に言うと、新しい機能を追加する際に既存のコードを変更せずに拡張できるべきという原則になります。

例として、オンラインストアの注文処理システムを考えてみましょう。以下のコードでは商品を表すクラスと注文処理クラスがあります。

class Product {
  String name;
  double price;

  Product(this.name, this.price);
}

class OrderProcessor {
  List<Product> items = [];

  void addItem(Product product) {
    items.add(product);
  }

  double calculateTotal() {
    double total = 0;
    for (var item in items) {
      total += item.price;
    }
    return total;
  }
}

上記のソースコードでは商品をカートに追加して、合計金額を計算することができます。ここで、新しい要件として商品に税金が適用されるようになった場合、どのようにしてOCPを遵守して拡張できるようにするのでしょうか？

開放/閉鎖の原則に違反している例

class OrderProcessor {
  List<Product> items = [];

  void addItem(Product product) {
    items.add(product);
  }

  double calculateTotal() {
    double total = 0;
    for (var item in items) {
      total += item.price;
    }
    return total;
  }

  double calculateTotalWithTax() {
    double total = calculateTotal();
    return total * 1.1; // 10% の税金を適用
  }
}

上記のコードでは、税金を計算するという新しい用件に適合するために、calculateTotalWithTaxメソッドを追加しました。しかし、これはOCPには違反しています。なぜなら新しい税金ルールが追加されるたびに、このクラスを変更する必要があるからです。そこで、以下のようにコードを修正します。

開放/閉鎖の原則を遵守している例

abstract class TaxCalculator {
  double calculateTax(double subtotal);
}

class OrderProcessor {
  List<Product> items = [];
  TaxCalculator taxCalculator; // TaxCalculatorのインスタンスを保持

  OrderProcessor(this.taxCalculator); // TaxCalculatorのインスタンスを注入

  void addItem(Product product) {
    items.add(product);
  }

  double calculateTotal() {
    double total = 0;
    for (var item in items) {
      total += item.price;
    }
    return total;
  }

  double calculateTotalWithTax() {
    double subtotal = calculateTotal();
    double tax = taxCalculator.calculateTax(subtotal);
    return subtotal + tax;
  }
}

class TenPercentTaxCalculator implements TaxCalculator {
  @override
  double calculateTax(double subtotal) {
    return subtotal * 0.1; // 10% の税金を適用
  }
}

上記のコードではまず、税金を計算するという新しい要件に従って、機能を拡張するために、TaxCalculatorという抽象クラスを作成しています。抽象クラスで作成することによって、異なる税金計算方法の実装を追加できるようになるのです。

次に、OrderProcesserクラスに税金計算のためのTaxCaluculatorインスタンスを保持させて、税金を計算します。これにより、新しい税金計算方法を追加するたびに、既存のコードを変更せずに新しい計算方法を利用できます。

最後に、10%の税金を適用するTenPercentTaxCalculatorクラスを作成します。この設計により、既存のOrderProcessorクラスは変更せずに、新しいTaxCalculatorの実装を注入するだけで新しい税金計算を利用できるようになります。

このように、OCPを遵守した設計は既存のコードを修正する必要がなく、新しい要件に対応することができます。これによって、システム全体の安定性が維持されるのです。

リスコフの置換原則 (Liskov Substitution Principle - LSP)

サブクラスはその親クラスと互換性があり、サブクラスのインスタンスは親クラスのインスタンスとして振る舞えるべきという原則です。簡単にいうと、クラスを継承するときは継承元と継承先のクラスの振る舞いを同じにしようという原則です。

例として、車(スーパークラス)とタクシー(サブクラス)クラスを考えてみましょう。以下のコードではTaxiクラスはCarクラスをextendsして継承しています。

継承の目的は、メソッドやプロパティをスーパークラスに定義してコードの重複をなくすことです。継承はis-aの関係(A is a Bは、AはBの一種である)が成立していなければいけません。以下のコードを見ると、タクシーは車の一種であるが成り立ちます。

リスコフの置換原則に違反している例

class Car {
  void start() {
    print('Car is starting');
  }

  void stop() {
    print('Car is stopping');
  }
}

class Taxi extends Car {
  // タクシーはスタート時にドアをロックする
  @override
  void start() {
    print('Taxi is starting and locking the door');
  }
}

void main() {
  Car car = Taxi(); // タクシーをCar型の変数に代入
  car.start(); // タクシーのstart()メソッドを呼び出し
  car.stop(); // Carのstop()メソッドを呼び出し
}

しかし、上記のコードではリスコフの置換原則に違反しています。なぜならCarクラスとTaxiクラスでは振る舞いが変わっているからです。

LSPに従うためには、サブクラスは親クラスのメソッドを置換し、その振る舞いを拡張することができても、変更してはいけません。しかし、Taxiクラスではstartメソッドが親クラスのCarクラスのstartメソッドの振る舞いを変更しています。このため、Car型の変数にTaxiオブジェクトを代入した場合、startメソッドの振る舞いが予測できなくなります。そこで、以下のようにコードを修正します。

リスコフの置換原則を遵守している例

abstract class Vehicle {
  void start();
  void stop();
}

class Car implements Vehicle {
  @override
  void start() {
    print('Car is starting');
  }

  @override
  void stop() {
    print('Car is stopping');
  }
}

class Taxi implements Vehicle {
  @override
  void start() {
    print('Taxi is starting and locking the door');
  }

  @override
  void stop() {
    print('Taxi is stopping');
  }
}

void main() {
  Vehicle vehicle = Taxi(); // タクシーをVehicle型の変数に代入
  vehicle.start(); // タクシーのstart()メソッドを呼び出し
  vehicle.stop(); // タクシーのstop()メソッドを呼び出し
}

上記のコードでは、CarとTaxiクラスは共にVehicleクラスを実装しています。このようにすることで、どちらのクラスもstartとstopメソッドを持ち、互換性があるようになります。LSPが遵守されているため、Vehicle型の変数にCarまたはTaxiオブジェクトを代入しても、予測可能な動作が得られるようになるのです。

インターフェース分離の原則 (Interface Segregation Principle - ISP)

クライアントは使用しないメソッドに依存すべきではないという原則です。クライアントが必要としないメソッドに依存しないためには、インターフェースを小さく、特定の用途に合わせて分割する必要があります。

例として、動物クラスで考えてみましょう。以下のコードではAnimalクラスという抽象クラスを元にCrow(カラス)クラス、Turtle(カメ)クラスをimplements(実装)しています。

インターフェース分離の原則に違反している例

// インターフェース
abstract class Animal {
  void sleep();
  void fly();
  void swim();
}

class Crow implements Animal {
  @override
  void sleep() {
    // 睡眠の処理
  }

  @override
  void fly() {
    // 飛行の処理
  }

  @override
  void swim() {
    // 泳ぎの処理
  }
}

class Turtle implements Animal {
  @override
  void sleep() {
    // 睡眠の処理
  }

  @override
  void fly() {
    // 飛行の処理
  }

  @override
  void swim() {
    // 泳ぎの処理
  }
}

上記のコードではCrowクラスにswimメソッドがあり、Turtleクラスにflyメソッドがあります。しかし、実際にカラスは泳ぐことができませんし、カメは飛ぶことができません。つまり上記のコードではISPに違反しています。そこで、以下のようにコードを修正します。

インターフェース分離の原則を遵守している例

// インターフェース
abstract class Sleep {
  void sleep();
}

abstract class Fly {
  void fly();
}

abstract class Swim {
  void swim();
}

class Crow implements Sleep, Fly {
  @override
  void sleep() {
    // 睡眠の処理
  }

  @override
  void fly() {
    // 飛行の処理
  }
}

class Turtle implements Sleep, Swim {
  @override
  void sleep() {
    // 睡眠の処理
  }

  @override
  void swim() {
    // 泳ぎの処理
  }
}

上記のようにインターフェースを小さい単位に分離させることで、各クライアントは利用するメソッドだけに依存するようになり、他のクライアントの変更の影響を最小限に抑えることができるようになります。

ISPを遵守することによって、クライアントが不要な依存関係を持たないようになります。そうすることで、シンプルなコードになり、コードの理解とメンテナンスが容易になるのです。

依存性逆転の原則 (Dependency Inversion Principle - DIP)

上位モジュールは下位モジュールに依存してはいけず、両者は抽象に依存すべきで、また具体的な実装は抽象に依存すべきであり、抽象は具体的な実装に依存するべきではないという原則です。

簡単にいうとプログラムの重要な部分が、重要でない部分に依存しないよう設計すべきで、抽象的な実装は具体的な実装に依存すべきではないということです。

例として電子メールを考えてみましょう。

依存性逆転の原則に違反している例

class EmailSender {
  void sendEmail(String recipient, String message) {
    // メールを送信する具体的な実装
  }
}

class EmailService {
  EmailSender sender = EmailSender();

  void sendEmail(String recipient, String message) {
    // EmailSenderの具体的な実装に依存している
    sender.sendEmail(recipient, message);
  }
}

上記のコードではEmailServiceクラスが具体的なEmailSenderクラスに依存しています。これは依存性逆転の原則に違反しています。なぜなら、高レベル(抽象)のEmailServiceクラスが低レベル(具体)のEmailSenderクラスに直接依存しており、抽象に依存していないからです。そこで、以下のようにコードを修正します。

依存性逆転の原則を遵守している例

abstract class MessageSender {
  void sendMessage(String recipient, String message);
}

class EmailSender implements MessageSender {
  @override
  void sendMessage(String recipient, String message) {
    print('Sending an email to $recipient: $message');
  }
}

class SMSSender implements MessageSender {
  @override
  void sendMessage(String recipient, String message) {
    print('Sending an SMS to $recipient: $message');
  }
}

class MessageService {
  late MessageSender sender;

  MessageService(MessageSender sender) {
    this.sender = sender;
  }

  void sendMessage(String recipient, String message) {
    // MessageSenderに依存しているが、具体的な実装には依存していない
    sender.sendMessage(recipient, message);
  }
}

void main() {
  // EmailSenderを使ってメッセージを送信する例
  final emailSender = EmailSender();
  final emailService = MessageService(emailSender);
  emailService.sendMessage('example@example.com', 'Hello, this is an email!');
  // Sending an email to example@example.com: Hello, this is an email!

  // SMSSenderを使ってメッセージを送信する例
  final smsSender = SMSSender();
  final smsService = MessageService(smsSender);
  smsService.sendMessage('1234567890', 'Hello, this is an SMS!');
  // Sending an SMS to 1234567890: Hello, this is an SMS!

}

上記のコードでは、MessageServiceクラスは抽象的なMessageSenderクラスに依存しており、具体的な実装には依存していません。具体的な送信方法はMessageSenderの実装クラスで行われています。このようにすることで、新しい送信方法を追加する場合でも、MessageServiceクラスの変更は不要で、DIPに遵守した設計となるのです。

DIPに遵守した設計にすることによって、コードのカプセル化と柔軟性が向上し、依存関係の変更に強くなります。

参考資料