SOLID를 사용하여 유연한 코드 작성

번역자: 당신을 위해 출판되었습니다 Severin Perez의 기사 프로그래밍에서 SOLID 원칙을 사용하는 방법에 대해 알아보세요. 이 기사의 정보는 초보자와 숙련된 프로그래머 모두에게 유용할 것입니다.

개발에 종사하고 있다면 SOLID 원칙에 대해 들어보셨을 것입니다. 이를 통해 프로그래머는 깨끗하고 체계적이며 유지 관리가 쉬운 코드를 작성할 수 있습니다. 프로그래밍에는 특정 작업을 올바르게 수행하는 방법에 대한 여러 가지 접근 방식이 있다는 점은 주목할 가치가 있습니다. 전문가마다 "올바른 길"에 대한 생각과 이해가 다르며, 이는 모두 각 개인의 경험에 따라 다릅니다. 그러나 SOLID에서 선언된 아이디어는 IT 커뮤니티의 거의 모든 대표자들에 의해 받아들여집니다. 이는 많은 훌륭한 개발 관리 관행의 출현과 발전을 위한 출발점이 되었습니다.

SOLID 원칙이 무엇인지, 그리고 그것이 우리에게 어떻게 도움이 되는지 이해해 봅시다.

Skillbox는 다음을 권장합니다. 실기 코스 "모바일 개발자 PRO".

알림: "Habr"의 모든 독자를 위한 - "Habr" 프로모션 코드를 사용하여 Skillbox 과정에 등록할 때 10 루블 할인.

솔리드란 무엇입니까?

이 용어는 약어이며 용어의 각 문자는 특정 원칙 이름의 시작 부분입니다.

• S단일 책임 원칙. 모듈에는 변경 이유가 하나만 있을 수 있습니다.
• XNUMXD덴탈의 O펜/폐쇄원리 (개방/폐쇄 원칙). 클래스와 기타 요소는 확장을 위해 열려야 하지만 수정을 위해서는 닫혀 있어야 합니다.
•  XNUMXD덴탈의 Liskov 대체 원리 (리스코프 대체 원리). 기본 유형을 사용하는 함수는 이를 알지 못한 채 기본 유형의 하위 유형을 사용할 수 있어야 합니다.
• XNUMXD덴탈의 I인터페이스 분리 원칙  (인터페이스 분리 원리). 소프트웨어 엔터티는 자신이 사용하지 않는 방법에 의존해서는 안 됩니다.
• XNUMXD덴탈의 D의존성 반전 원리 (의존성 역전의 원리) 높은 수준의 모듈은 낮은 수준의 모듈에 의존해서는 안 됩니다.

단일 책임 원칙

 
SRP(단일 책임 원칙)는 프로그램의 각 클래스나 모듈이 해당 프로그램 기능의 한 부분만 담당해야 한다고 명시합니다. 또한 이 책임의 요소는 관련 없는 클래스에 분산되기보다는 자체 클래스에 할당되어야 합니다. SRP의 개발자이자 수석 전도사인 Robert S. Martin은 책임을 변화의 이유로 설명합니다. 그는 원래 이 용어를 그의 작품 "객체 지향 설계의 원리"의 요소 중 하나로 제안했습니다. 이 개념은 이전에 Tom DeMarco가 정의한 연결 패턴의 대부분을 통합합니다.

이 개념에는 David Parnas가 공식화한 여러 개념도 포함되었습니다. 두 가지 주요한 것은 캡슐화와 정보 은닉입니다. 파르나스는 시스템을 별도의 모듈로 나누는 것이 블록 다이어그램이나 실행 흐름 분석을 기반으로 해서는 안 된다고 주장했습니다. 모든 모듈에는 클라이언트에게 최소한의 정보를 제공하는 특정 솔루션이 포함되어야 합니다.

그런데 Martin은 각기 다른 목적으로 특정 비즈니스 소프트웨어를 사용하는 회사의 고위 관리자(COO, CTO, CFO)와 함께 흥미로운 예를 제시했습니다. 결과적으로 이들 중 누구라도 다른 관리자의 이익에 영향을 주지 않고 소프트웨어 변경 사항을 구현할 수 있습니다.

신성한 대상

언제나 그렇듯이 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 클래스는 모든 것을 알고 모든 일을 하는 전형적인 "신 개체"입니다. 이는 객체 지향 프로그래밍의 주요 안티 패턴입니다. 초보자의 경우 이러한 개체는 유지 관리가 매우 어렵습니다. 지금까지 프로그램은 매우 간단했습니다. 그렇습니다. 하지만 새로운 기능을 추가하면 어떤 일이 일어날지 상상해 보세요. 아마도 우리 우주 정거장에는 의료 스테이션이나 회의실이 필요할 것입니다. 그리고 기능이 많아질수록 우주정거장은 더욱 커질 것입니다. 글쎄요, 이 시설은 다른 시설과 연결될 것이기 때문에 전체 단지에 대한 서비스는 더욱 복잡해질 것입니다. 결과적으로 가속기 등의 작동을 방해할 수 있습니다. 연구원이 센서 변경을 요청하면 이는 스테이션의 통신 시스템에 큰 영향을 미칠 수 있습니다.

SRP 원칙을 어기면 단기적으로는 전술적 승리를 거둘 수 있을지 모르지만 결국에는 “전쟁에서 패하게” 되고 앞으로도 이런 괴물을 유지하기가 매우 어려워질 것입니다. 프로그램을 각각 특정 작업을 수행하는 별도의 코드 섹션으로 나누는 것이 가장 좋습니다. 이를 이해하고 SpaceStation 클래스를 변경해 보겠습니다.

책임을 분산시키자

위에서 우리는 SpaceStation 클래스에 의해 제어되는 네 가지 유형의 작업을 정의했습니다. 리팩토링할 때 이를 염두에 두겠습니다. 업데이트된 코드는 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 클래스는 센서 세트, 소모품 공급 시스템, 연료 탱크 및 부스터를 포함한 종속 부품에 대한 작업이 시작되는 컨테이너에 더 가깝습니다.

모든 변수에 대해 이제 해당 클래스인 센서가 있습니다. 공급 보류; 연료 탱크; 추진기.

이 버전의 코드에는 몇 가지 중요한 변경 사항이 있습니다. 요점은 개별 함수가 자체 클래스에 캡슐화될 뿐만 아니라 예측 가능하고 일관성을 갖도록 구성된다는 것입니다. 일관성의 원칙을 따르기 위해 유사한 기능을 가진 요소를 그룹화합니다. 이제 해시 구조에서 배열로 이동하여 시스템 작동 방식을 변경해야 하는 경우 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.

이 최신 버전의 프로그램에서는 책임이 FuelReporter와 SupplyReporter라는 두 개의 새로운 클래스로 나누어졌습니다. 둘 다 Reporter 클래스의 자식입니다. 또한 필요한 경우 원하는 하위 클래스를 초기화할 수 있도록 SpaceStation 클래스에 인스턴스 변수를 추가했습니다. 이제 지구가 다른 것을 변경하기로 결정하면 메인 클래스가 아닌 하위 클래스를 변경하게 됩니다.

물론 일부 수업은 여전히 ​​서로 의존하고 있습니다. 따라서 SupplyReporter 개체는 SupplyHold에 종속되고 FuelReporter는 FuelTank에 종속됩니다. 물론 부스터는 연료탱크에 연결되어 있어야 합니다. 그러나 여기에서는 모든 것이 이미 논리적으로 보이며 변경하는 것이 특별히 어렵지 않습니다. 한 개체의 코드를 편집해도 다른 개체에 큰 영향을 미치지 않습니다.

따라서 우리는 각 개체/클래스의 책임이 정확하게 정의된 모듈식 코드를 만들었습니다. 이러한 코드로 작업하는 것은 문제가 되지 않으며 유지 관리는 간단한 작업입니다. "신성한 물체" 전체를 SRP로 변환했습니다.

Skillbox는 다음을 권장합니다.

• XNUMX년 실습 코스 "저는 PRO 웹 개발자입니다".
• 온라인 코스 "0의 C# 개발자".
• 실기 코스 "0에서 PRO로의 PHP 개발자".

출처 : habr.com