Пишем гъвкав код, използвайки SOLID

От преводача: публикуваме за вас статия на Северин Перес за използването на принципите SOLID в програмирането. Информацията от статията ще бъде полезна както на начинаещи, така и на опитни програмисти.

Ако се занимавате с разработка, вероятно сте чули за принципите SOLID. Те дават възможност на програмистите да пишат чист, добре структуриран и лесно обслужваем код. Струва си да се отбележи, че в програмирането съществуват различни подходи как правилно да се извършва дадена работа. Различните специалисти имат различни идеи и разбирания за 'правилния път', всичко зависи от опита на всеки. Въпреки това, идеите, провъзгласени в SOLID, са приети почти от всички представители на ИТ-общността. Те станаха отправна точка за възникването и развитието на множество добри методи за управление на разработката.

Нека разгледаме какво представляват принципите SOLID и как те ни помагат.

Skillbox препоръчва: Практически курс «Мобилен разработчик ПРО».

Напомняме: за всички читатели на «Хабра» — отстъпка от 10 000 рубли при записване на всеки курс Skillbox с промокод «Хабр».

Какво е SOLID?

Терминът е абревиатура, всяка буква от термина е начало на определен принцип:

• SПринцип на единствената отговорност. Модулът може да има само една причина за промяна.
• The OПринцип на откритост/закритост. Класовете и другите елементи трябва да бъдат отворени за разширение, но затворени за модификации.
•  The LПринцип на подмяната на Лисков. Функциите, които използват базов тип, трябва да могат да използват подтипове на базовия тип, без да знаят за това.
• The IПринцип на разделяне на интерфейса.Програмирането не трябва да зависи от методи, които не използва.
• The DПринцип на инверсия на зависимости. Модулите на по-високи нива не трябва да зависят от модулите на по-ниски нива.

Принцип на единствената отговорност

 
Принцип на единната отговорност (SRP) гласи, че всеки клас или модул в програмата трябва да носи отговорност само за една част от функционалността на тази програма. Освен това, елементите на тази отговорност трябва да бъдат свързани със съответния клас, а не разпределени между несвързани класове. Разработчикът и главният евангелист на SRP, Робърт С. Мартин, описва отговорността като причина за промяна. Първоначално той предложи този термин като един от елементите в своята работа "Принципи на обектно-ориентираното проектиране". В концепцията са включени много от закономерностите на свързаността, предложени по-рано от Том Демарко.

В концепцията са включени и няколко понятия, формулирани от Дейвид Парнас. Двете основни са инкапсулация и скриване на информация. Парнас твърдеше, че разделението на системата на отделни модули не трябва да се основава на анализ на блок-схеми или потоци на изпълнение. Всеки от модулите трябва да съдържа конкретно решение, което предоставя минимално количество информация на клиентите.

Мартин даде интересен пример с висшите мениджъри на компанията (COO, CTO, CFO), всеки от които използва специфичен софтуер за бизнеса с различна цел. В резултат, всеки от тях може да внедри промени в софтуера, без да засяга интересите на другите мениджъри.

Божествен обект

Както обикновено, най-добрият начин да се научите на SRP е да видите всичко в действие. Нека да разгледаме част от програмата, която НЕ отговаря на принципа на единната отговорност. Това е Ruby код, описващ поведението и атрибутите на космическата станция.

Прегледайте примера и опитайте да определите следното:
Отговорностите на обектите, които са обявени в класа SpaceStation.
Тези, които може да проявят интерес към работата на космическата станция.

клас SpaceStation
  деф инициализиране
    @снабдяване = {}
    @гориво = 0
  край
 
  деф работи_сензори
    постави "----- Действие на сензора -----"
    постави "Изпълнявам сензорите!"
  край
 
  деф зареди_снабдяване(тип, количество)
    постави "----- Действие на снабдяването -----"
    постави "Зареждам #{количество} единици от #{тип} в склада за снабдяване."
    
    ако @снабдяване[тип]
      @снабдяване[тип] += количество
    иначе
      @снабдяване[тип] = количество
    край
  край
 
  деф използвай_снабдяване(тип, количество)
    постави "----- Действие на снабдяването -----"
    ако @снабдяване[тип] != nil && @снабдяване[тип] > количество
      постави "Използвам #{количество} от #{тип} от склада за снабдяване."
      @снабдяване[тип] -= количество
    иначе
      постави "Грешка в снабдяването: Недостатъчно #{тип} в склада за снабдяване."
    край
  край
 
  деф докладвай_снабдяване
    постави "----- Справка за снабдяването -----"
    ако @снабдяване.ключове.дължина > 0
      @снабдяване.всяко направи |тип, количество|
        постави "#{тип} налични: #{количеството} единици"
      край
    иначе
      постави "Складът за снабдяване е празен."
    край
  край
 
  деф зареди_гориво(количество)
    постави "----- Действие за горивото -----"
    постави "Зареждам #{количество} единици гориво в резервоара."
    @гориво += количество
  край
 
  деф докладвай_гориво
    постави "----- Справка за горивото -----"
    постави "#{@гориво} единици гориво налични."
  край
 
  деф активирай_ускорителите
    постави "----- Действие на ускорителите -----"
    ако @гориво >= 10
      постави "Действието на тласкането е успешно."
      @гориво -= 10
    иначе
      постави "Грешка на ускорителите: Недостатъчно гориво налично."
    край
  край
край

Всъщност, нашата космическа станция не е функционална (не мисля, че ще получа обаждане от NASA в близко обозримо бъдеще), но тук има какво да анализираме.

Така, класът SpaceStation има няколко различни отговорности (или задачи). Всички те могат да бъдат разделени по типове:

• сензори;
• снабдяване (разходни материали);
• гориво;
• ускорители.

Въпреки че никой от служителите на станцията не е определен в класа, можем лесно да си представим кой за какво отговаря. Най-вероятно научният работник контролира сензорите, логистикът отговаря за снабдяването с ресурси, инженерът се грижи за запасите от гориво, а пилотът контролира усилвателите.

Можем ли да кажем, че тази програма не отговаря на SRP? Да, разбира се. Но класът SpaceStation е типичен "божествен обект", който знае всичко и прави всичко. Това е основният антипатерн в обектно-ориентираното програмиране. За начинаещ такива обекти са изключително сложни за поддръжка. В момента програмата е много проста, да, но си представете какво ще стане, ако добавим нови функции. Вероятно нашата космическа станция ще се нуждае от медицински пункт или заседателна зала. И колкото повече функции добавяме, толкова повече ще расте SpaceStation. А тъй като този обект ще е свързан с другите, поддръжката на целия комплекс ще стане още по-сложна. В крайна сметка можем да нарушим работата, например, на ускорителите. Ако научният сътрудник поиска промени в работата със сензорите, това напълно може да повлияе на комуникационните системи на станцията.

Нарушаването на принципа SRP може да даде краткосрочна тактическа победа, но в крайна сметка ще "загубим войната"; обслужването на такъв монстър в бъдеще ще стане много трудно. Най-добре е да разделим програмата на отделни участъци код, всеки от които отговаря за извършването на определена операция. Разбирайки това, нека променим класа SpaceStation.

Разпределяме отговорностите

По-горе определихме четири типа операции, които се контролират от класа SpaceStation. При рефактурирането ще ги имаме предвид. Актуализираният код по-добре отговаря на SRP.

клас 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
 
клас Sensors
  def run_sensors
    puts "----- Действие на сензора -----"
    puts "Сензорите работят!"
  end
end
 
клас SupplyHold
  attr_accessor :supplies
 
  def initialize
    @supplies = {}
  end
 
  def load_supplies(type, quantity)
    puts "----- Действие на запасите -----"
    puts "Зареждане на #{quantity} единици от #{type} в резервната част."
    
    if @supplies[type]
      @supplies[type] += quantity
    else
      @supplies[type] = quantity
    end
  end
 
  def use_supplies(type, quantity)
    puts "----- Действие на запасите -----"
    if @supplies[type] != nil && @supplies[type] > quantity
      puts "Използване на #{quantity} от #{type} от резервната част."
      @supplies[type] -= quantity
    else
      puts "Грешка в запаса: Недостатъчно #{type} в резервната част."
    end
  end
 
  def report_supplies
    puts "----- Доклад за запасите -----"
    if @supplies.keys.length > 0
      @supplies.each do |type, quantity|
        puts "#{type} налично: #{quantity} единици"
      end
    else
      puts "Резервната част е празна."
    end
  end
end
 
клас FuelTank
  attr_accessor :fuel
 
  def initialize
    @fuel = 0
  end
 
  def get_fuel_levels
    @fuel
  end
 
  def load_fuel(quantity)
    puts "----- Действие на горивото -----"
    puts "Зареждане на #{quantity} единици гориво в резервоара."
    @fuel += quantity
  end
 
  def use_fuel(quantity)
    puts "----- Действие на горивото -----"
    puts "Използване на #{quantity} единици гориво от резервоара."
    @fuel -= quantity
  end
 
  def report_fuel
    puts "----- Доклад за горивото -----"
    puts "#{@fuel} единици гориво налично."
  end
end
 
клас Thrusters
  def initialize(fuel_tank)
    @linked_fuel_tank = fuel_tank
  end
 
  def activate_thrusters
    puts "----- Действие на ускорителите -----"
    if @linked_fuel_tank.get_fuel_levels >= 10
      puts "Действието на усилване е успешно."
      @linked_fuel_tank.use_fuel(10)
    else
      puts "Грешка в ускорителя: Недостатъчно гориво налично."
    end
  end
end

Промените са много, програмата сега изглежда определено по-добре. Сега нашият клас SpaceStation стана по-скоро контейнер, в който се инициират операции за зависимите части, включително комплект сензори, система за подаване на консумативи, резервоар за гориво и ускорители.

За всяка от променливите сега има съответен клас: Sensors; SupplyHold; FuelTank; Thrusters.

В тази версия на кода има няколко важни промени. Функциите не само че са инкапсулирани в собствени класове, но са организирани така, че да станат предсказуеми и последователни. Групираме подобни по функционалност елементи, за да следваме принципа на свързаност. Сега, ако трябва да променим начина на работа на системата, преминавайки от хеш структура на масив, просто използваме класа SupplyHold, без да се налага да засягаме други модули. Така, ако офицерът, отговорен за логистиката, направи промяна в своята секция, останалите елементи на станцията ще останат незасегнати. Класът SpaceStation дори няма да бъде информиран за промените.

Нашите офицери, работещи на космическата станция, вероятно са доволни от промените, тъй като могат да поискат точно това, което им е необходимо. Обърнете внимание, че в кода има методи като report_supplies и report_fuel, които са част от класовете SupplyHold и FuelTank. Какво ще стане, ако Земята поиска да промени начина на формирование на отчетите? Ще е необходимо да променим и двата класа, 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  0
      @linked_item.get_supplies.each do |type, quantity|
        puts "#{type} available: #{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 available: 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 препоръчва:

• Двугодишен практически курс «Аз съм уеб разработчик PRO».
• Онлайн курс «C# разработчик от 0».
• Практически годишен курс «PHP разработчик от 0 до PRO».

Източник: habr.com