Пишување флексибилен код користејќи SOLID

Од преведувачот: објавено за вас напис од Северин Перез за користење на SOLID принципи во програмирањето. Информациите од статијата ќе бидат корисни и за почетници и за искусни програмери.

Ако сте во развој, најверојатно сте слушнале за принципите SOLID. Тие му овозможуваат на програмерот да пишува чист, добро структуриран и лесно одржуван код. Вреди да се напомене дека во програмирањето постојат неколку пристапи за тоа како правилно да се изврши одредена работа. Различни специјалисти имаат различни идеи и разбирање за „вистинскиот пат“; сето тоа зависи од искуството на секоја личност. Сепак, идеите прокламирани во SOLID се прифатени од речиси сите претставници на ИТ заедницата. Тие станаа почетна точка за појавата и развојот на многу добри практики за управување со развојот.

Ајде да разбереме кои се СОЛИД принципите и како ни помагаат.

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

Потсетуваме: за сите читатели на „Хабр“ - попуст од 10 рубли при запишување на кој било курс Skillbox користејќи го промотивниот код „Хабр“.

Што е ЦВРСТ?

Овој термин е кратенка, секоја буква од терминот е почеток на името на одреден принцип:

• Single Принцип на одговорност. Модулот може да има една и само една причина за промена.
• на Oпенкало/Затворен принцип (принцип на отворено/затворено). Класите и другите елементи треба да бидат отворени за продолжување, но затворени за модификација.
•  на LИсков Принцип на замена (принцип на замена на Лисков). Функциите што користат основен тип треба да можат да користат подтипови од основниот тип без да го знаат тоа.
• на IПринцип на сегрегација на интерфејс  (принцип на одвојување на интерфејс). Софтверските ентитети не треба да зависат од методи што не ги користат.
• на Dнезависност Принцип на инверзија (принцип на инверзија на зависност). Модулите на повисоките нивоа не треба да зависат од модулите на пониските нивоа.

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

 
Принципот на единствена одговорност (SRP) вели дека секоја класа или модул во програмата треба да биде одговорна само за еден дел од функционалноста на таа програма. Дополнително, елементите на оваа одговорност треба да се доделат на нивната класа, наместо да се расфрлаат низ неповрзани класи. Развивачот и главен евангелист на SRP, Роберт С. Мартин, ја опишува одговорноста како причина за промена. Тој првично го предложи овој термин како еден од елементите на неговата работа „Принципи на објектно-ориентиран дизајн“. Концептот вклучува голем дел од шемата за поврзување што претходно беше дефинирана од Том Демарко.

Концептот вклучуваше и неколку концепти формулирани од Дејвид Парнас. Двете главни се енкапсулација и криење на информации. Парнас тврдеше дека поделбата на системот на посебни модули не треба да се заснова на анализа на блок дијаграми или текови на извршување. Било кој од модулите мора да содржи специфично решение кое обезбедува минимум информации за клиентите.

Инаку, Мартин даде интересен пример со високи менаџери на една компанија (COO, CTO, CFO), од кои секој користи специфичен деловен софтвер за различни цели. Како резултат на тоа, секој од нив може да спроведе промени во софтверот без да влијае на интересите на другите менаџери.

Божествен предмет

Како и секогаш, најдобриот начин да се научи SRP е да се види на дело. Ајде да погледнеме дел од програмата што НЕ го следи Принципот на единствена одговорност. Ова е кодот Руби кој го опишува однесувањето и атрибутите на вселенската станица.

Прегледајте го примерот и обидете се да го одредите следново:
Одговорности на оние објекти кои се декларирани во класата 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 ќе расте. Па, бидејќи овој објект ќе биде поврзан со други, сервисирањето на целиот комплекс ќе стане уште покомплексно. Како резултат на тоа, можеме да ја нарушиме работата на, на пример, акцелераторите. Ако истражувачот побара промени на сензорите, тоа може многу добро да влијае на комуникациските системи на станицата.

Прекршувањето на принципот СРП може да даде краткорочна тактичка победа, но на крајот ќе ја „изгубиме војната“ и ќе биде многу тешко да се одржи такво чудовиште во иднина. Најдобро е да се подели програмата на посебни делови од кодот, од кои секоја е одговорна за извршување на одредена операција. Разбирање на ова, ајде да ја смениме класата 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, ќе треба да се променат. Што ако треба да го промените начинот на испорака на гориво и потрошен материјал? Веројатно ќе треба повторно да ги промените сите исти часови. И ова е веќе кршење на принципот 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. И двајцата се деца од класата Репортер. Дополнително, додадовме променливи на пример во класата SpaceStation за да може саканата подкласа да се иницијализира доколку е потребно. Сега, ако Земјата одлучи да промени нешто друго, тогаш ќе направиме промени во подкласите, а не во главната класа.

Се разбира, некои од нашите часови сè уште зависат еден од друг. Така, објектот SupplyReporter зависи од SupplyHold, а FuelReporter зависи од FuelTank. Се разбира, засилувачите мора да бидат поврзани со резервоарот за гориво. Но, овде сè веќе изгледа логично, а правењето промени нема да биде особено тешко - уредувањето на кодот на еден објект нема многу да влијае на друг.

Така, создадовме модуларен код каде што се прецизно дефинирани одговорностите на секој од објектите/класите. Работењето со таков код не е проблем, неговото одржување ќе биде едноставна задача. Целиот „божествен објект“ го претворивме во SRP.

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

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

Извор: www.habr.com