მოქნილი კოდის დაწერა SOLID-ის გამოყენებით

მთარგმნელისგან: გამოქვეყნდა თქვენთვის სევერინ პერესის სტატია SOLID პრინციპების გამოყენების შესახებ პროგრამირებაში. სტატიიდან მიღებული ინფორმაცია სასარგებლო იქნება როგორც დამწყებთათვის, ასევე გამოცდილი პროგრამისტებისთვის.

თუ თქვენ ხართ განვითარებაში, დიდი ალბათობით გსმენიათ SOLID პრინციპების შესახებ. ისინი პროგრამისტს საშუალებას აძლევს დაწეროს სუფთა, კარგად სტრუქტურირებული და ადვილად შესანახი კოდი. აღსანიშნავია, რომ პროგრამირებაში არსებობს რამდენიმე მიდგომა, თუ როგორ სწორად შეასრულოთ კონკრეტული სამუშაო. სხვადასხვა სპეციალისტს განსხვავებული იდეები და გაგება აქვთ „სწორი გზის“ შესახებ, ეს ყველაფერი დამოკიდებულია თითოეული ადამიანის გამოცდილებაზე. თუმცა, SOLID-ში გამოცხადებული იდეები მიღებულია IT საზოგადოების თითქმის ყველა წარმომადგენლის მიერ. ისინი გახდნენ საწყისი წერტილი განვითარების მართვის მრავალი კარგი პრაქტიკის გაჩენისა და განვითარებისათვის.

მოდით გავიგოთ, რა არის SOLID პრინციპები და როგორ გვეხმარება ისინი.

Skillbox გირჩევთ: პრაქტიკული კურსი "Mobile Developer PRO".

შეგახსენებთ: "Habr"-ის ყველა მკითხველისთვის - ფასდაკლება 10 რუბლიდან Skillbox-ის ნებისმიერ კურსზე ჩარიცხვისას "Habr" სარეკლამო კოდის გამოყენებით.

რა არის SOLID?

ეს ტერმინი არის აბრევიატურა, ტერმინის თითოეული ასო არის კონკრეტული პრინციპის სახელის დასაწყისი:

• Sერთიანი პასუხისმგებლობის პრინციპი. მოდულს შეიძლება ჰქონდეს ცვლილების ერთი და მხოლოდ ერთი მიზეზი.
• ის 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

სინამდვილეში, ჩვენი კოსმოსური სადგური უფუნქციოა (არამგონია, მალე დამირეკოს NASA-დან), მაგრამ აქ არის რაღაც გასაანალიზებელი.

ამრიგად, 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, უნდა შეიცვალოს. რა მოხდება, თუ თქვენ გჭირდებათ საწვავის და სახარჯო მასალების მიწოდების წესის შეცვლა? თქვენ ალბათ ისევ მოგიწევთ იგივე კლასის შეცვლა. და ეს უკვე 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