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

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

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

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

Skillbox препоръчва: Практически курс „Мобилен разработчик PRO“.

Напомняме ви: за всички читатели на "Habr" - отстъпка от 10 000 рубли при записване във всеки курс Skillbox, използвайки промоционалния код на "Habr".

Какво е SOLID?

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

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

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

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

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

Между другото, Мартин даде интересен пример с висши мениджъри на компания (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

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

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

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

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

Можем ли да кажем, че тази програма не е съвместима с SRP? Да, разбира се. Но класът SpaceStation е типичен „богообект“, който знае всичко и прави всичко. Това е основен анти-шаблон в обектно-ориентираното програмиране. За начинаещ такива обекти са изключително трудни за поддръжка. Засега програмата е много проста, да, но представете си какво ще стане, ако добавим нови функции. Може би нашата космическа станция ще се нуждае от медицинска станция или зала за срещи. И колкото повече функции има, толкова повече ще расте 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; Резервоар за гориво; Тласкачи.

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

Нашите служители, работещи на космическата станция, вероятно са доволни от промените, защото могат да поискат тези, от които се нуждаят. Забележете, че кодът има методи като report_supplies и report_fuel, съдържащи се в класовете SupplyHold и FuelTank. Какво ще се случи, ако Земята поиска да промени начина, по който докладва? И двата класа, SupplyHold и FuelTank, ще трябва да бъдат променени. Ами ако трябва да промените начина на доставка на гориво и консумативи? Вероятно ще трябва да промените всички същите класове отново. А това вече е нарушение на принципа на КРП. Нека поправим това.

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. И двамата са деца от клас „Репортер“. Освен това добавихме променливи на екземпляр към класа SpaceStation, така че желаният подклас да може да бъде инициализиран, ако е необходимо. Сега, ако Земята реши да промени нещо друго, тогава ние ще направим промени в подкласовете, а не в основния клас.

Разбира се, някои от нашите класове все още зависят един от друг. По този начин обектът SupplyReporter зависи от SupplyHold, а FuelReporter зависи от FuelTank. Разбира се, бустерите трябва да бъдат свързани към резервоара за гориво. Но тук всичко вече изглежда логично и извършването на промени няма да бъде особено трудно - редактирането на кода на един обект няма да засегне значително друг.

Така създадохме модулен код, в който отговорностите на всеки от обектите/класовете са точно дефинирани. Работата с такъв код не е проблем, поддържането му ще бъде проста задача. Преобразувахме целия „божествен обект“ в SRP.

Skillbox препоръчва:

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

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