Объектно ориентированный дизайн

Дизайн ООП
правила хорошего тона. SOLID.

Щербинин Александр
undev.ru

Объектно ориентированное проектирование

• проектирование - суть программирования

• ваш код - проектная документация продукта

• задача проектирования - управление сложностью
проекта

Ароматы дизайна
или как распознать загнивающий код

• непрозрачность


- сложность для понимания, запутанность



• жесткость




- сложность внесения изменений





- простое изменение вызывает каскад зависимых
правок





правок

• хрупкость





правок

• хрупкость

- исправление одной проблемы влечет появление
множества новых


• неподвижность



- сложно выделить части дизайна в отдельные
компоненты




• вязкость





- сложно сохранить дизайн при изменении





- сложно сохранить дизайн при изменении

- решить задачу правильно сложнее, чем сделать
“хак”


• ненужная сложность



- наблюдается overhead, наличие множества
неиспользуемых элементов




- возникает, когда разработчик пытается
предугадать последующие изменения





• ненужные повторения





• ненужные повторения

- один и тот же код с минимальными изменениями
копируется снова и снова

SOLID

• Single responsibility principle

• Open/closed principle

• Liskov substitution principle

• Interface segregation principle

• Dependency inversion principle

Single responsibility principle
Принцип единственной обязанности

SRP

SRP

• у класса должна быть только одна причина для
изменения

SRP

изменения

• то есть у класса должна быть только одна
обязанность

SRP

изменения

• то есть у класса должна быть только одна
обязанность

• сильное сцепление (high cohesion, см. GRASP)

SRP

class Modem
  def dial(number)
  end 1-я обязанность
  def hangup
управление соединением
  end

  def send(char)
  end
2-я обязанность
  def recv передача данных
  end
end

SRP
module ConnectionInterface
  def dial(number)
  end

  def hangup class Modem
  end   include ConnectionInterface
end   include DataChannelInterface
end
module DataChannelInterface
  def send(char)
  end

  def recv
  end
end

SRP
class Modem
  def dial(number)
управление соединением
  def hangup
  end

  def send(char)
передача данных
  def recv
  end
end

Если необходимо изменить только процесс соединения - то дизайн
становится жестким, и нужно разделять обязанности

Если изменяется одновременно и процесс соединения, и процесс
отправки - то разделение повлечет за собой излишнюю сложность

SRP

class Basket
  def calculate бизнес-логика
  end

  def store
  end логика приложения
end

SRP

• не совмещайте бизнес-логику с логикой
приложения

SRP

• не совмещайте бизнес-логику с логикой
приложения

• если вам очень-очень нужно совместить
обязанности - не создавайте зависимостей

Open/closed principle
Принцип открытости/закрытости

OCP

OCP

• программные сущности должны быть открыты для
расширения, но закрыты для модификации

OCP


• открыты для расширения - мы можем изменить состав
модуля, добавив новое поведение

OCP


• открыты для расширения - мы можем изменить состав
модуля, добавив новое поведение

• закрыты для модификации - расширение модуля не
связано с изменением его исходного кода (уменьшаем
жесткость)

OCP

Задача: необходимо рисовать геометрические фигуры
(круги и квадраты) в графическом интерфейсе.

OCP
wrong
(высокая жесткость)
Circle = Struct.new(:radius, :center)

# рисуем круг
def draw_circle
  #
end

Square = Struct.new(:side, :top_left)

# рисуем квадрат
def draw_square
  #
end

# рисуем список фигур
def draw_all_shapes(shapes)
  shapes.each do |shape|
    case shape.class
      when Circle; draw_circle(shape)
      when Square; draw_square(shape)
    end
  end
end

OCP
wrong better
(высокая жесткость)
Circle = Struct.new(:radius, :center) class Shape
  def draw
# рисуем круг     # interface
def draw_circle   end
  # end
end
class Circle < Shape
Square = Struct.new(:side, :top_left)   def draw
    # implement
# рисуем квадрат   end
def draw_square end
  #
end class Square < Shape
  def draw
# рисуем список фигур     # implement
def draw_all_shapes(shapes)   end
  shapes.each do |shape| end
    case shape.class
      when Circle; draw_circle(shape) def draw_all_shapes(shapes)
      when Square; draw_square(shape)   shapes.each do |shape|
    end     shape.draw
  end   end
end end

OCP
• не существует моделей, универсальных во всех
контекстах

OCP

• защищайся только от наиболее вероятных изменений

OCP


• не беги вперед и не перегружай код абстракциями
(помни про ненужную сложность)

OCP



• “Обманул меня раз - позор тебе. Обманул два - позор
мне”

OCP



• “Обманул меня раз - позор тебе. Обманул два - позор
мне”

• отказ от абстракции так же важен, как и ее ввод

Liskov substitution principle
Принцип подстановки Лисков

LSP

LSP

• должна быть возможность вместо базового типа
подставить любой его подтип

LSP


• поведение наследуемых классов не должно
противоречить поведению, заданному базовым классом

LSP


• поведение наследуемых классов не должно
противоречить поведению, заданному базовым классом

• LSP - важнейший критерий оценки качества при
построении иерархий наследования

LSP
class Rectangle
  def width
    return @width
  end

  def height
    return @height
  end

  def width=(number)
    @width = number
  end

  def height=(number)
    @height = number
  end
end

LSP
class Rectangle class Square < Rectangle
  def width   def width=(number)
    return @width     @width = number
  end     @height = number
  end
  def height
    return @height   def height=(number)
  end     @width = number
    @height = number
  end
  def width=(number) end
    @width = number
  end

  def height=(number)
    @height = number
  end
end

LSP
  end
  def height
  end     @width = number
    @height = number
  end
    @width = number
  end

  def height=(number)
    @height = number
  end def foo(rectangle)
end   rectangle.width = 5
  rectangle.height = 7
end

LSP
  end
  def height
  end     @width = number
    @height = number
  # assert((width == number) && (height = old.height))   end
    @width = number
  end

  def height=(number)
    @height = number
  end def foo(rectangle)
end   rectangle.width = 5
  rectangle.height = 7
end

LSP

• проектирование по контракту (пред- и пост- условия)

LSP


• производный класс не должен исключать
функциональность базового класса

LSP


• производный класс не должен исключать
функциональность базового класса

• если классы имеют некоторую общую обязанность -
возможно имеет смысл провести факторизацию

Interface segregation principle
Принцип разделения интерфейсов

ISP

ISP

• клиент не должен вынужденно зависеть от элементов
интерфейса, которые он не использует

ISP


• “жирные” интерфейсы - плохо

ISP


• “жирные” интерфейсы - плохо

• интерфейс считается “жирным”, когда между его
методами слабая сцепленность (см. GRASP)

ISP

class ServiceClient
  def send_data; end
  def flush; end
end

class HttpServiceClient < ServiceClient
  def send_data
    # implement
  end

  def flush
    # пустой метод, остаток от интерфейса
  end
end

class BufferingHttpServiceClient < ServiceClient
  def send_data
    # another implement
  end

  def flush
    # implement
  end
end

ISP

class ServiceClient class ServiceClient
  def send_data; end   def send_data; end
  def flush; end end
end
class BufferingServiceClient < ServiceClient
class HttpServiceClient < ServiceClient   def flush; end
  def send_data end
    # implement
  end
class HttpServiceClient < ServiceClient
  def flush   def send_data
    # пустой метод, остаток от интерфейса     # implement
  end   end
end end

class BufferingHttpServiceClient < ServiceClient class BufferingHttpServiceClient < BufferingServiceClient
  def send_data   def send_data
    # another implement     # another implement
  end   end

  def flush   def flush
    # implement     # implement
  end   end
end end

ISP

Как разделять?

ISP

• делегация

ISP

• делегация

• множественное наследование

Dependency-inversion principle
Принцип инверсии зависимости

DIP

DIP

• модули верхнего уровня не должны зависеть от
модулей нижнего уровня. И те и другие должны
зависеть от абстракций

DIP


• абстракции не должны зависеть от деталей. Детали
должны зависеть от абстракций

DIP


• абстракции не должны зависеть от деталей. Детали
должны зависеть от абстракций

• если коротко: зависеть надо от абстракций

DIP
до
class Program
  def self.run
    reporter = Reporter.new
    reporter.send_reports()
  end
end

class Reporter
  def initialize
    @builder = ReportBuilder.new
    @sender = EmailReportSender.new
  end

  def send_reports
    reports = @builder.create_reports()
    reports.each do |report|
      @sender.send(report)
    end
  end
end

Program.run

DIP
до
class Program
class Program   def self.run
  def self.run
# builder, sender - реализации соответствующих интерфейсов
    builder = ReportBuilder.new
    sender = EmailReportSender.new
  end
    reporter = Reporter.new(builder, sender)
end
  end
class Reporter
end
  def initialize
class Reporter
  def initialize(builder, sender)
  end
    @builder = builder
    @sender = sender
  def send_reports
  end
  def send_reports
    end
  end
end
    end
  end
Program.run
end

Program.run

DIP
до после
class Program
class Program   def self.run
  def self.run
# builder, sender - реализации соответствующих интерфейсов
    builder = ReportBuilder.new
    sender = EmailReportSender.new
  end
    reporter = Reporter.new(builder, sender)
end
  end
class Reporter
end
  def initialize
class Reporter
  def initialize(builder, sender)
  end
    @builder = builder
    @sender = sender
  def send_reports
  end
  def send_reports
    end
  end
end
    end
  end
Program.run
end

Program.run

DIP

до

DIP

до после

Советую прочитать


• GRASP - General Responsibility Assignment Software
Patterns


Patterns

• Принципы, паттерны, и методики гибкой разработки на
языке C#. // Р. С. Мартин, М. Мартин.


Patterns


• Шаблоны корпоративных приложений. // М. Фаулер


Patterns



• Предметно-ориентированное проектирование (DDD).
Структуризация сложных систем. // Э. Эванс


Patterns



• Предметно-ориентированное проектирование (DDD).
Структуризация сложных систем. // Э. Эванс

• Паттерны проектирования. // GoF

That’s all

Вопросы?

Щербинин Александр
undev.ru
twitter.com/realmyst
github.com/realmyst

Объектно ориентированный дизайн

Recommended

Recommended

More Related Content

Similar to Объектно ориентированный дизайн

Similar to Объектно ориентированный дизайн (20)

Объектно ориентированный дизайн

Editor's Notes