SOLID を使用して柔軟なコードを作成する

翻訳者より: あなたのために公開されました セベリン・ペレスによる記事 プログラミングにおける SOLID 原則の使用について。 この記事の情報は、初心者にも経験豊富なプログラマーにも役立ちます。

開発に興味がある人なら、SOLID 原則について聞いたことがあるでしょう。 これらにより、プログラマーは、クリーンで適切に構造化された、保守が容易なコードを作成できます。 プログラミングでは、特定のジョブを正しく実行する方法がいくつかあることは注目に値します。 専門家によって「正しい道」に対する考え方や理解は異なり、それはすべて各人の経験に依存します。 しかし、SOLID で宣言されたアイデアは、IT コミュニティのほぼすべての代表者に受け入れられています。 これらは、多くの優れた開発管理慣行の出現と発展の出発点となりました。

SOLID 原則とは何なのか、そしてそれがどのように役立つのかを理解しましょう。

スキルボックスは次のことを推奨します。 実践コース 「モバイルデベロッパーPRO」.

リマインダー： 「Habr」のすべての読者が対象 - 「Habr」プロモーション コードを使用してスキルボックス コースに登録すると 10 ルーブルの割引。

ソリッドとは何ですか?

この用語は略語であり、用語の各文字は特定の原則の名前の始まりです。

• S責任原則。 モジュールが持つことができる変更の理由は XNUMX つだけです。
• 　 Oペン/閉鎖原理 (オープン/クローズ原則)。 クラスとその他の要素は、拡張のためにオープンである必要がありますが、変更のためにクローズされている必要があります。
•  　 Liskov 置換原則 （リスコフ置換原理）。 基本型を使用する関数は、意識せずに基本型のサブタイプを使用できる必要があります。
• 　 Iインターフェース分離原理  （界面分離原理）。 ソフトウェア エンティティは、使用しないメソッドに依存すべきではありません。
• 　 D依存関係の逆転原理 (依存関係逆転の原理)。 より高いレベルのモジュールは、より低いレベルのモジュールに依存しないでください。

単一責任の原則

 
単一責任原則 (SRP) では、プログラム内の各クラスまたはモジュールは、そのプログラムの機能の XNUMX つの部分のみを担当すべきであると規定されています。 さらに、この責任の要素は、無関係なクラスに分散するのではなく、独自のクラスに割り当てられる必要があります。 SRP の開発者でありチーフエバンジェリストである Robert S. Martin 氏は、変化の理由として説明責任があると述べています。 彼はもともとこの用語を彼の著作「オブジェクト指向設計の原則」の要素の XNUMX つとして提案しました。 このコンセプトには、Tom DeMarco によって以前に定義された接続パターンの多くが組み込まれています。

この概念には、David Parnas によって策定されたいくつかの概念も含まれていました。 主なものは、カプセル化と情報隠蔽の XNUMX つです。 Parnas 氏は、システムを個別のモジュールに分割するのは、ブロック図や実行フローの分析に基づくべきではないと主張しました。 いずれのモジュールにも、クライアントに最小限の情報を提供する特定のソリューションが含まれている必要があります。

ところで、Martin 氏は、企業の上級マネージャー (COO、CTO、CFO) について興味深い例を挙げました。彼らはそれぞれ、異なる目的で特定のビジネス ソフトウェアを使用しています。 その結果、どの管理者も、他の管理者の利益に影響を与えることなくソフトウェアの変更を実装できます。

ご神体

いつものように、SRP を学ぶ最善の方法は、実際に SRP が動作しているのを見ることです。 単一責任原則に従っていないプログラムのセクションを見てみましょう。 これは、宇宙ステーションの動作と属性を記述する Ruby コードです。

例を確認して、次の点を判断してください。
SpaceStation クラスで宣言されたオブジェクトの責任。
宇宙ステーションの運用に興味のある方。

class SpaceStation
  def initialize
    @supplies = {}
    @fuel = 0
  end
 
  def run_sensors
    puts "----- Sensor Action -----"
    puts "Running sensors!"
  end
 
  def load_supplies(type, quantity)
    puts "----- Supply Action -----"
    puts "Loading #{quantity} units of #{type} in the supply hold."
    
    if @supplies[type]
      @supplies[type] += quantity
    else
      @supplies[type] = quantity
    end
  end
 
  def use_supplies(type, quantity)
    puts "----- Supply Action -----"
    if @supplies[type] != nil && @supplies[type] > quantity
      puts "Using #{quantity} of #{type} from the supply hold."
      @supplies[type] -= quantity
    else
      puts "Supply Error: Insufficient #{type} in the supply hold."
    end
  end
 
  def report_supplies
    puts "----- Supply Report -----"
    if @supplies.keys.length > 0
      @supplies.each do |type, quantity|
        puts "#{type} avalilable: #{quantity} units"
      end
    else
      puts "Supply hold is empty."
    end
  end
 
  def load_fuel(quantity)
    puts "----- Fuel Action -----"
    puts "Loading #{quantity} units of fuel in the tank."
    @fuel += quantity
  end
 
  def report_fuel
    puts "----- Fuel Report -----"
    puts "#{@fuel} units of fuel available."
  end
 
  def activate_thrusters
    puts "----- Thruster Action -----"
    if @fuel >= 10
      puts "Thrusting action successful."
      @fuel -= 10
    else
      puts "Thruster Error: Insufficient fuel available."
    end
  end
end

実際、私たちの宇宙ステーションは機能不全に陥っています（すぐに NASA から連絡が来るとは思いません）が、ここで分析すべきことがあります。

したがって、SpaceStation クラスにはいくつかの異なる責任 (またはタスク) があります。 それらはすべて次のタイプに分類できます。

• センサー;
• 消耗品（消耗品）。
• 燃料;
• 加速器。

駅の従業員に階級が割り当てられていないとしても、誰が何を担当するのかは容易に想像できます。 おそらく、科学者はセンサーを制御し、物流担当者は資源の供給を担当し、エンジニアは燃料の供給を担当し、パイロットはブースターを制御します。

このプログラムは SRP に準拠していないと言えますか? はい、確かに。 しかし、SpaceStation クラスは、すべてを知り、すべてを実行する典型的な「神オブジェクト」です。 これは、オブジェクト指向プログラミングにおける主なアンチパターンです。 初心者にとって、そのようなオブジェクトを保守するのは非常に困難です。 ここまでのプログラムは非常にシンプルですが、新しい機能を追加するとどうなるかを想像してみてください。 おそらく私たちの宇宙ステーションには医療ステーションや会議室が必要になるでしょう。 そして、機能が増えれば増えるほど、SpaceStation はさらに成長していきます。 この施設は他の施設と接続されるため、複合施設全体のメンテナンスはさらに複雑になります。 その結果、加速器などの動作に支障をきたす可能性があります。 研究者がセンサーの変更を要求すると、ステーションの通信システムに影響を与える可能性が非常に高くなります。

SRP原則に違反すると、短期的には戦術的に勝利を収めることができるかもしれないが、最終的には「戦争に負ける」ことになり、将来的にそのような怪物を維持することは非常に困難になるだろう。 プログラムをコードの別々のセクションに分割し、それぞれが特定の操作の実行を担当することが最善です。 これを理解した上で、SpaceStation クラスを変更してみましょう。

責任を分散しましょう

上記では、SpaceStation クラスによって制御される XNUMX 種類の操作を定義しました。 リファクタリングの際にはそれらを念頭に置いていきます。 更新されたコードは SRP とよりよく一致します。

class SpaceStation
  attr_reader :sensors, :supply_hold, :fuel_tank, :thrusters
 
  def initialize
    @supply_hold = SupplyHold.new
    @sensors = Sensors.new
    @fuel_tank = FuelTank.new
    @thrusters = Thrusters.new(@fuel_tank)
  end
end
 
class Sensors
  def run_sensors
    puts "----- Sensor Action -----"
    puts "Running sensors!"
  end
end
 
class SupplyHold
  attr_accessor :supplies
 
  def initialize
    @supplies = {}
  end
 
  def load_supplies(type, quantity)
    puts "----- Supply Action -----"
    puts "Loading #{quantity} units of #{type} in the supply hold."
    
    if @supplies[type]
      @supplies[type] += quantity
    else
      @supplies[type] = quantity
    end
  end
 
  def use_supplies(type, quantity)
    puts "----- Supply Action -----"
    if @supplies[type] != nil && @supplies[type] > quantity
      puts "Using #{quantity} of #{type} from the supply hold."
      @supplies[type] -= quantity
    else
      puts "Supply Error: Insufficient #{type} in the supply hold."
    end
  end
 
  def report_supplies
    puts "----- Supply Report -----"
    if @supplies.keys.length > 0
      @supplies.each do |type, quantity|
        puts "#{type} avalilable: #{quantity} units"
      end
    else
      puts "Supply hold is empty."
    end
  end
end
 
class FuelTank
  attr_accessor :fuel
 
  def initialize
    @fuel = 0
  end
 
  def get_fuel_levels
    @fuel
  end
 
  def load_fuel(quantity)
    puts "----- Fuel Action -----"
    puts "Loading #{quantity} units of fuel in the tank."
    @fuel += quantity
  end
 
  def use_fuel(quantity)
    puts "----- Fuel Action -----"
    puts "Using #{quantity} units of fuel from the tank."
    @fuel -= quantity
  end
 
  def report_fuel
    puts "----- Fuel Report -----"
    puts "#{@fuel} units of fuel available."
  end
end
 
class Thrusters
  def initialize(fuel_tank)
    @linked_fuel_tank = fuel_tank
  end
 
  def activate_thrusters
    puts "----- Thruster Action -----"
    if @linked_fuel_tank.get_fuel_levels >= 10
      puts "Thrusting action successful."
      @linked_fuel_tank.use_fuel(10)
    else
      puts "Thruster Error: Insufficient fuel available."
    end
  end
end

多くの変更が加えられ、プログラムの見た目は確実に良くなりました。 現在、SpaceStation クラスは、センサーのセット、消耗品供給システム、燃料タンク、ブースターなどの依存部品の操作が開始されるコンテナーのようなものになりました。

どの変数にも、対応するクラス「Sensors」が存在します。 サプライホールド; 燃料タンク; スラスター。

このバージョンのコードにはいくつかの重要な変更があります。 重要なのは、個々の関数が独自のクラスにカプセル化されるだけでなく、予測可能で一貫性のある方法で編成されるということです。 一貫性の原則に従って、同様の機能を持つ要素をグループ化します。 これで、システムの動作方法を変更して、ハッシュ構造から配列に移行する必要がある場合は、SupplyHold クラスを使用するだけでよく、他のモジュールに触れる必要はありません。 こうすることで、物流担当者が自分のセクションで何かを変更しても、ステーションの残りの部分はそのまま残ります。 この場合、SpaceStation クラスは変更を認識することさえありません。

宇宙ステーションで働く職員たちは、必要な変更をリクエストできるため、おそらくこの変更に満足しているでしょう。 コードには、SupplyHold クラスや FuelTank クラスに含まれる report_supplies や report_fuel などのメソッドがあることに注意してください。 地球が報道方法を変えるよう求めたらどうなるでしょうか? SupplyHold と FuelTank の両方のクラスを変更する必要があります。 燃料と消耗品の配送方法を変更する必要がある場合はどうすればよいですか? おそらく、同じクラスをすべて再度変更する必要があるでしょう。 そしてこれはすでに SRP 原則に違反しています。 これを修正しましょう。

class SpaceStation
  attr_reader :sensors, :supply_hold, :supply_reporter,
              :fuel_tank, :fuel_reporter, :thrusters
 
  def initialize
    @sensors = Sensors.new
    @supply_hold = SupplyHold.new
    @supply_reporter = SupplyReporter.new(@supply_hold)
    @fuel_tank = FuelTank.new
    @fuel_reporter = FuelReporter.new(@fuel_tank)
    @thrusters = Thrusters.new(@fuel_tank)
  end
end
 
class Sensors
  def run_sensors
    puts "----- Sensor Action -----"
    puts "Running sensors!"
  end
end
 
class SupplyHold
  attr_accessor :supplies
  attr_reader :reporter
 
  def initialize
    @supplies = {}
  end
 
  def get_supplies
    @supplies
  end
 
  def load_supplies(type, quantity)
    puts "----- Supply Action -----"
    puts "Loading #{quantity} units of #{type} in the supply hold."
    
    if @supplies[type]
      @supplies[type] += quantity
    else
      @supplies[type] = quantity
    end
  end
 
  def use_supplies(type, quantity)
    puts "----- Supply Action -----"
    if @supplies[type] != nil && @supplies[type] > quantity
      puts "Using #{quantity} of #{type} from the supply hold."
      @supplies[type] -= quantity
    else
      puts "Supply Error: Insufficient #{type} in the supply hold."
    end
  end
end
 
class FuelTank
  attr_accessor :fuel
  attr_reader :reporter
 
  def initialize
    @fuel = 0
  end
 
  def get_fuel_levels
    @fuel
  end
 
  def load_fuel(quantity)
    puts "----- Fuel Action -----"
    puts "Loading #{quantity} units of fuel in the tank."
    @fuel += quantity
  end
 
  def use_fuel(quantity)
    puts "----- Fuel Action -----"
    puts "Using #{quantity} units of fuel from the tank."
    @fuel -= quantity
  end
end
 
class Thrusters
  FUEL_PER_THRUST = 10
 
  def initialize(fuel_tank)
    @linked_fuel_tank = fuel_tank
  end
 
  def activate_thrusters
    puts "----- Thruster Action -----"
    
    if @linked_fuel_tank.get_fuel_levels >= FUEL_PER_THRUST
      puts "Thrusting action successful."
      @linked_fuel_tank.use_fuel(FUEL_PER_THRUST)
    else
      puts "Thruster Error: Insufficient fuel available."
    end
  end
end
 
class Reporter
  def initialize(item, type)
    @linked_item = item
    @type = type
  end
 
  def report
    puts "----- #{@type.capitalize} Report -----"
  end
end
 
class FuelReporter < Reporter
  def initialize(item)
    super(item, "fuel")
  end
 
  def report
    super
    puts "#{@linked_item.get_fuel_levels} units of fuel available."
  end
end
 
class SupplyReporter < Reporter
  def initialize(item)
    super(item, "supply")
  end
 
  def report
    super
    if @linked_item.get_supplies.keys.length > 0
      @linked_item.get_supplies.each do |type, quantity|
        puts "#{type} avalilable: #{quantity} units"
      end
    else
      puts "Supply hold is empty."
    end
  end
end
 
iss = SpaceStation.new
 
iss.sensors.run_sensors
  # ----- Sensor Action -----
  # Running sensors!
 
iss.supply_hold.use_supplies("parts", 2)
  # ----- Supply Action -----
  # Supply Error: Insufficient parts in the supply hold.
iss.supply_hold.load_supplies("parts", 10)
  # ----- Supply Action -----
  # Loading 10 units of parts in the supply hold.
iss.supply_hold.use_supplies("parts", 2)
  # ----- Supply Action -----
  # Using 2 of parts from the supply hold.
iss.supply_reporter.report
  # ----- Supply Report -----
  # parts avalilable: 8 units
 
iss.thrusters.activate_thrusters
  # ----- Thruster Action -----
  # Thruster Error: Insufficient fuel available.
iss.fuel_tank.load_fuel(100)
  # ----- Fuel Action -----
  # Loading 100 units of fuel in the tank.
iss.thrusters.activate_thrusters
  # ----- Thruster Action -----
  # Thrusting action successful.
  # ----- Fuel Action -----
  # Using 10 units of fuel from the tank.
iss.fuel_reporter.report
  # ----- Fuel Report -----
# 90 units of fuel available.

このプログラムの最新バージョンでは、役割が XNUMX つの新しいクラス、FuelReporter と SupplyReporter に分割されました。 彼らは両方とも Reporter クラスの子供です。 さらに、必要に応じて目的のサブクラスを初期化できるように、SpaceStation クラスにインスタンス変数を追加しました。 さて、地球が何か他のものを変更することを決定した場合、メインクラスではなくサブクラスに変更を加えます。

もちろん、クラスの中には依然として相互に依存しているものもあります。 したがって、SupplyReporter オブジェクトは SupplyHold に依存し、FuelReporter は FuelTank に依存します。 もちろんブースターは燃料タンクに接続する必要があります。 しかし、ここではすべてがすでに論理的に見えており、変更を加えるのは特に難しいことではありません。あるオブジェクトのコードを編集しても、他のオブジェクトに大きな影響を与えることはありません。

したがって、各オブジェクト/クラスの役割が正確に定義されたモジュール式コードを作成しました。 このようなコードの操作は問題なく、メンテナンスは簡単な作業です。 「ご神体」を丸ごとSRP化しました。

スキルボックスは次のことを推奨します。

• XNUMX年間の実践コース 「私はプロのウェブ開発者です」.
• オンラインコース 「0からのC#開発者」.
• 実践一年コース 「0からPROまでのPHP開発者」.

出所： habr.com