SlideShare ist ein Scribd-Unternehmen logo
1 von 36
Downloaden Sie, um offline zu lesen
SOLID
     GRASP
основные принципы ООП
SOLID
Буква Акро-   англ.                   рус.
      ним
      SRP     Single responsibility   Принцип единственной
  S
              principle               обязанности
      OCP     Open/closed principle   Принцип
 O
                                      открытости/закрытости
      LSP     Liskov substitution     Принцип подстановки
  L
              principle               Барбары Лисков
      ISP     Interface segregation   Принцип изоляции
  I
              principle               интерфейса
      DIP     Dependency inversion Принцип инверсии
 D
              principle            зависимостей
Single responsibility principle
    Принцип единственной обязанности

На каждый объект должна быть возложена одна
         единственная обязанность.
смешенная ответственность




разделенная ответственность
Open/closed principle
      Принцип открытости/закрытости

Программные сущности должны быть открыты для
    расширения, но закрыты для изменения.
открытая "кухня"




закрытая "кухня"
Liskov substitution principle
   Принцип подстановки Барбары Лисков

 Объекты в программе могут быть заменены их
наследниками без изменения свойств программы.
кот и пес не смогут стать животными :)
треугольник может стать фигурой
Interface segregation principle
        Принцип изоляции интерфейса

Много специализированных интерфейсов лучше, чем
              один универсальный.
жирный интерфейс




набор тонких специализированных интерфейсов
Dependency inversion principle
            Принцип инверсии зависимостей

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

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




слабая зависимость
GRASP
General Responsibility Assignment Software Patterns
  №   англ.                  рус.
  1   Information Expert     Информационный эксперт
  2   Creator                Создатель
  3   Controller             Контроллер
  4   Low Coupling           Слабая связанность
  5   High Cohesion          Сильное зацепление
  6   Polymorphism           Полиморфизм
  7   Pure Fabrication       Чистая выдумка
  8   Indirection            Посредник
  9   Protected Variations   Сокрытие реализации
Information Expert
         Информационный эксперт

   обязанности должны быть назначены
  объекту, который владеет максимумом
необходимой информации для выполнения
обязанности (информационному эксперту).

      Тривиально, но очень важно!
Creator
                     Создатель

    Это применение шаблона Information
    Expert к проблеме создания объектов.

Класс B должен (может) создавать объекты
             класса A когда:
●   Класс B содержит или агрегирует объекты A.
●   Класс B записывает экземпляры объектов A.
●   Класс B активно использует объекты A
●   Класс B обладает данными инициализации для
    объектов A.
Abstract Factory
Абстрактная фабрика
Builder
Строитель
Controller
                    Контроллер

     Берет на себя ответственность за
   выполнение операций, приходящих от
              пользователя.

    Как правило, не выполняет работу
самостоятельно, а делегирует обязанности
         компетентным объектам.

Пример: Model-View-Controller
Low Coupling
                     Слабая связанность

Распределяет обязанности между
объектами таким образом, чтобы степень
связанности между системами оставалась
низкой.
Степень связанности (coupling) — это мера, определяющая, насколько
жестко один элемент связан с другими элементами, либо каким
количеством данных о других элементах он обладает.

Свойства элемента с низкой степенью связанности(слабым связыванием):
●   Малое число зависимостей между классами (подсистемами).
●   Слабая зависимость одного класса (подсистемы) от изменений в
    другом классе (подсистеме).
●   Высокая степень повторного использования подсистем.
High Cohesion
        Сильное (функциональное) зацепление

     Задает свойство сильного зацепления
             внутри подсистемы.
Зацепление (cohesion) (функциональное зацепление) — это мера
связанности и сфокусированности обязанностей класса.


Объект обладает высокой степенью зацепления, если
его обязанности тесно связаны между собой и он не
выполняет огромных объемов работы.

Antipattern: God object
Polymorphism
                  Полиморфизм

 Позволяет обрабатывать альтернативные
  варианты поведения на основе типа и
   заменять подключаемые компоненты
                системы.

Все альтернативные реализации приводятся к общему
интерфейсу.
Pure Fabrication
              Чистая выдумка

 Класс, не отражающий никакого реального
объекта предметной области, но специально
  придуманный для усиления зацепления,
  ослабления связанности или увеличения
    степени повторного использования.
Indirection
                    Посредник

  Поддерживает слабую связанность путём
 назначения обязанностей промежуточному
                 объекту.

Пример: Model-View-Controller
Protected Variations
           Сокрытие реализации

Защищает элементы от изменения других
  элементов, вынося взаимодействия в
      фиксированный интерфейс.

Поведение может варьироваться лишь с помощью
   создания другой реализации интерфейса.
SOLID & GRASP

Weitere ähnliche Inhalte

Was ist angesagt?

Шаблоны разработки ПО. Часть 2. ООП и UML
Шаблоны разработки ПО. Часть 2. ООП и UMLШаблоны разработки ПО. Часть 2. ООП и UML
Шаблоны разработки ПО. Часть 2. ООП и UML
Sergey Nemchinsky
 

Was ist angesagt? (20)

Web API The Good Partsの紹介 ~美しいWebAPIの作り方~
Web API The Good Partsの紹介 ~美しいWebAPIの作り方~Web API The Good Partsの紹介 ~美しいWebAPIの作り方~
Web API The Good Partsの紹介 ~美しいWebAPIの作り方~
 
SOLID Principles
SOLID PrinciplesSOLID Principles
SOLID Principles
 
#jjug_ccc #ccc_f1 広告システム刷新の舞台裏 - PHPからJavaに変えてみました
#jjug_ccc #ccc_f1 広告システム刷新の舞台裏 - PHPからJavaに変えてみました#jjug_ccc #ccc_f1 広告システム刷新の舞台裏 - PHPからJavaに変えてみました
#jjug_ccc #ccc_f1 広告システム刷新の舞台裏 - PHPからJavaに変えてみました
 
Redmineの活用事例‐多様なプロジェクト管理に対するツールの適用
Redmineの活用事例‐多様なプロジェクト管理に対するツールの適用Redmineの活用事例‐多様なプロジェクト管理に対するツールの適用
Redmineの活用事例‐多様なプロジェクト管理に対するツールの適用
 
【Interop Tokyo 2016】 初心者でもわかるCisco SDNの概要
【Interop Tokyo 2016】 初心者でもわかるCisco SDNの概要【Interop Tokyo 2016】 初心者でもわかるCisco SDNの概要
【Interop Tokyo 2016】 初心者でもわかるCisco SDNの概要
 
소프트웨어 아키텍처 문서화
소프트웨어 아키텍처 문서화소프트웨어 아키텍처 문서화
소프트웨어 아키텍처 문서화
 
Шаблоны разработки ПО. Часть 2. ООП и UML
Шаблоны разработки ПО. Часть 2. ООП и UMLШаблоны разработки ПО. Часть 2. ООП и UML
Шаблоны разработки ПО. Часть 2. ООП и UML
 
Design Patterns - Factory Method & Abstract Factory
Design Patterns - Factory Method & Abstract FactoryDesign Patterns - Factory Method & Abstract Factory
Design Patterns - Factory Method & Abstract Factory
 
Railsのデバッグ どうやるかを改めて確認する
Railsのデバッグ どうやるかを改めて確認するRailsのデバッグ どうやるかを改めて確認する
Railsのデバッグ どうやるかを改めて確認する
 
Конспект лекций по курсу "Шаблоны разработки ПО"
Конспект лекций по курсу "Шаблоны разработки ПО"Конспект лекций по курсу "Шаблоны разработки ПО"
Конспект лекций по курсу "Шаблоны разработки ПО"
 
The OO Design Principles
The OO Design PrinciplesThe OO Design Principles
The OO Design Principles
 
Secuencias y series gráficas
Secuencias y series gráficasSecuencias y series gráficas
Secuencias y series gráficas
 
はじめる! Redmine (2021年版)
はじめる! Redmine (2021年版) はじめる! Redmine (2021年版)
はじめる! Redmine (2021年版)
 
Software Design Patterns
Software Design PatternsSoftware Design Patterns
Software Design Patterns
 
OpenDaylight 소개
OpenDaylight 소개OpenDaylight 소개
OpenDaylight 소개
 
あなたが知らない リレーショナルモデル
あなたが知らない リレーショナルモデルあなたが知らない リレーショナルモデル
あなたが知らない リレーショナルモデル
 
Rakutenとsreと私 yanagimoto koichi
Rakutenとsreと私 yanagimoto koichiRakutenとsreと私 yanagimoto koichi
Rakutenとsreと私 yanagimoto koichi
 
cloudpackサーバ仕様書(サンプル)
cloudpackサーバ仕様書(サンプル)cloudpackサーバ仕様書(サンプル)
cloudpackサーバ仕様書(サンプル)
 
なぜ、いま リレーショナルモデルなのか(理論から学ぶデータベース実践入門読書会スペシャル)
なぜ、いま リレーショナルモデルなのか(理論から学ぶデータベース実践入門読書会スペシャル)なぜ、いま リレーショナルモデルなのか(理論から学ぶデータベース実践入門読書会スペシャル)
なぜ、いま リレーショナルモデルなのか(理論から学ぶデータベース実践入門読書会スペシャル)
 
PCCC20 日本オラクル株式会社「Oracle Cloud Infrastructure for HPC」
PCCC20 日本オラクル株式会社「Oracle Cloud Infrastructure for HPC」PCCC20 日本オラクル株式会社「Oracle Cloud Infrastructure for HPC」
PCCC20 日本オラクル株式会社「Oracle Cloud Infrastructure for HPC」
 

Andere mochten auch

Шаблоны разработки ПО. Часть 3. Шаблоны GoF
Шаблоны разработки ПО. Часть 3. Шаблоны GoFШаблоны разработки ПО. Часть 3. Шаблоны GoF
Шаблоны разработки ПО. Часть 3. Шаблоны GoF
Sergey Nemchinsky
 
android architecture
android architectureandroid architecture
android architecture
Aashita Gupta
 

Andere mochten auch (20)

Принципы проектирования S.O.L.I.D
Принципы проектирования S.O.L.I.DПринципы проектирования S.O.L.I.D
Принципы проектирования S.O.L.I.D
 
Разработка под Android для устройств разных разрешений и размеров
Разработка под Android для устройств разных разрешений и размеровРазработка под Android для устройств разных разрешений и размеров
Разработка под Android для устройств разных разрешений и размеров
 
Верстка для Андроид
Верстка для АндроидВерстка для Андроид
Верстка для Андроид
 
Design talk - GRASP Patterns
Design talk - GRASP PatternsDesign talk - GRASP Patterns
Design talk - GRASP Patterns
 
Александр Садовский "Как получить больше трафика"
Александр Садовский "Как получить больше трафика"Александр Садовский "Как получить больше трафика"
Александр Садовский "Как получить больше трафика"
 
SOLID Principles in the real world
SOLID Principles in the real worldSOLID Principles in the real world
SOLID Principles in the real world
 
7 типичных ошибок при запуске рекламной кампании во ВКонтакте
7 типичных ошибок при запуске рекламной кампании во ВКонтакте7 типичных ошибок при запуске рекламной кампании во ВКонтакте
7 типичных ошибок при запуске рекламной кампании во ВКонтакте
 
SOLID
SOLIDSOLID
SOLID
 
Шаблоны разработки ПО. Часть 3. Шаблоны GoF
Шаблоны разработки ПО. Часть 3. Шаблоны GoFШаблоны разработки ПО. Часть 3. Шаблоны GoF
Шаблоны разработки ПО. Часть 3. Шаблоны GoF
 
Сила букв: как текст объявления повышает CTR
Сила букв: как текст объявления повышает CTRСила букв: как текст объявления повышает CTR
Сила букв: как текст объявления повышает CTR
 
Как найти первую работу и как с нее не вылететь
Как найти первую работу и как с нее не вылететьКак найти первую работу и как с нее не вылететь
Как найти первую работу и как с нее не вылететь
 
Android architecture
Android architectureAndroid architecture
Android architecture
 
«Автотесты» Вадим Пуштаев, программист отдела внутренней разработки Поиска Ma...
«Автотесты» Вадим Пуштаев, программист отдела внутренней разработки Поиска Ma...«Автотесты» Вадим Пуштаев, программист отдела внутренней разработки Поиска Ma...
«Автотесты» Вадим Пуштаев, программист отдела внутренней разработки Поиска Ma...
 
Android Architecture
Android ArchitectureAndroid Architecture
Android Architecture
 
Grasp principles
Grasp principlesGrasp principles
Grasp principles
 
«Coro. Intro» Евгений Вансевич, программист Почты Mail.Ru
«Coro. Intro» Евгений Вансевич, программист Почты Mail.Ru«Coro. Intro» Евгений Вансевич, программист Почты Mail.Ru
«Coro. Intro» Евгений Вансевич, программист Почты Mail.Ru
 
09 grasp
09 grasp09 grasp
09 grasp
 
android architecture
android architectureandroid architecture
android architecture
 
GRASP Principles
GRASP PrinciplesGRASP Principles
GRASP Principles
 
Grasp
GraspGrasp
Grasp
 

Ähnlich wie SOLID & GRASP

SOLID. Принципы объектно ориентированного дизайна
SOLID. Принципы объектно ориентированного дизайнаSOLID. Принципы объектно ориентированного дизайна
SOLID. Принципы объектно ориентированного дизайна
Михаил Польгун
 
07 Архитектура информационных систем. Принципы GRASP
07 Архитектура информационных систем. Принципы GRASP07 Архитектура информационных систем. Принципы GRASP
07 Архитектура информационных систем. Принципы GRASP
Edward Galiaskarov
 
ZFConf 2011: Гибкая архитектура Zend Framework приложений с использованием De...
ZFConf 2011: Гибкая архитектура Zend Framework приложений с использованием De...ZFConf 2011: Гибкая архитектура Zend Framework приложений с использованием De...
ZFConf 2011: Гибкая архитектура Zend Framework приложений с использованием De...
ZFConf Conference
 
S.O.L.I.D. - Павел Кохан, Python Meetup 26.09.2014
S.O.L.I.D. - Павел Кохан, Python Meetup 26.09.2014S.O.L.I.D. - Павел Кохан, Python Meetup 26.09.2014
S.O.L.I.D. - Павел Кохан, Python Meetup 26.09.2014
Python Meetup
 
Инъекция зависимости и Инверсия Контроля
Инъекция зависимости и Инверсия КонтроляИнъекция зависимости и Инверсия Контроля
Инъекция зависимости и Инверсия Контроля
Vladimir Ignatev
 
DI and Zend Framework (ZFConf2011)
DI and Zend Framework (ZFConf2011)DI and Zend Framework (ZFConf2011)
DI and Zend Framework (ZFConf2011)
Alexey Kachayev
 

Ähnlich wie SOLID & GRASP (20)

Принципы SOLID
Принципы SOLIDПринципы SOLID
Принципы SOLID
 
SOLID
SOLIDSOLID
SOLID
 
SOLID. Принципы объектно ориентированного дизайна
SOLID. Принципы объектно ориентированного дизайнаSOLID. Принципы объектно ориентированного дизайна
SOLID. Принципы объектно ориентированного дизайна
 
SOLID && Magento2
SOLID && Magento2SOLID && Magento2
SOLID && Magento2
 
07 Архитектура информационных систем. Принципы GRASP
07 Архитектура информационных систем. Принципы GRASP07 Архитектура информационных систем. Принципы GRASP
07 Архитектура информационных систем. Принципы GRASP
 
шаблоны проектирования
шаблоны проектированияшаблоны проектирования
шаблоны проектирования
 
Проблемы точечной застройки в больших городах или зачем нужен Dagger
Проблемы точечной застройки в больших городах или зачем нужен DaggerПроблемы точечной застройки в больших городах или зачем нужен Dagger
Проблемы точечной застройки в больших городах или зачем нужен Dagger
 
Большие проекты, архитектура и фреймворки.
Большие проекты, архитектура и фреймворки.Большие проекты, архитектура и фреймворки.
Большие проекты, архитектура и фреймворки.
 
ZFConf 2011: Гибкая архитектура Zend Framework приложений с использованием De...
ZFConf 2011: Гибкая архитектура Zend Framework приложений с использованием De...ZFConf 2011: Гибкая архитектура Zend Framework приложений с использованием De...
ZFConf 2011: Гибкая архитектура Zend Framework приложений с использованием De...
 
SOLID
SOLIDSOLID
SOLID
 
Design principles
Design principles Design principles
Design principles
 
S.O.L.I.D. - Павел Кохан, Python Meetup 26.09.2014
S.O.L.I.D. - Павел Кохан, Python Meetup 26.09.2014S.O.L.I.D. - Павел Кохан, Python Meetup 26.09.2014
S.O.L.I.D. - Павел Кохан, Python Meetup 26.09.2014
 
Инъекция зависимости и Инверсия Контроля
Инъекция зависимости и Инверсия КонтроляИнъекция зависимости и Инверсия Контроля
Инъекция зависимости и Инверсия Контроля
 
Software Design Patterns
Software Design PatternsSoftware Design Patterns
Software Design Patterns
 
DESIGN PATTERNS? EASY!
DESIGN PATTERNS? EASY!DESIGN PATTERNS? EASY!
DESIGN PATTERNS? EASY!
 
SOLIDарность: Тестирование как разработка
SOLIDарность: Тестирование как разработкаSOLIDарность: Тестирование как разработка
SOLIDарность: Тестирование как разработка
 
Евгений Кривошеев: Фундаментальные правила и принципы проектирования ПО
Евгений Кривошеев: Фундаментальные правила и принципы проектирования ПОЕвгений Кривошеев: Фундаментальные правила и принципы проектирования ПО
Евгений Кривошеев: Фундаментальные правила и принципы проектирования ПО
 
Design Rules And Principles
Design Rules And PrinciplesDesign Rules And Principles
Design Rules And Principles
 
DI and Zend Framework (ZFConf2011)
DI and Zend Framework (ZFConf2011)DI and Zend Framework (ZFConf2011)
DI and Zend Framework (ZFConf2011)
 
Solid code via tdd
Solid code via tddSolid code via tdd
Solid code via tdd
 

SOLID & GRASP

  • 1. SOLID GRASP основные принципы ООП
  • 2.
  • 3. SOLID Буква Акро- англ. рус. ним SRP Single responsibility Принцип единственной S principle обязанности OCP Open/closed principle Принцип O открытости/закрытости LSP Liskov substitution Принцип подстановки L principle Барбары Лисков ISP Interface segregation Принцип изоляции I principle интерфейса DIP Dependency inversion Принцип инверсии D principle зависимостей
  • 4.
  • 5. Single responsibility principle Принцип единственной обязанности На каждый объект должна быть возложена одна единственная обязанность.
  • 7.
  • 8. Open/closed principle Принцип открытости/закрытости Программные сущности должны быть открыты для расширения, но закрыты для изменения.
  • 10.
  • 11. Liskov substitution principle Принцип подстановки Барбары Лисков Объекты в программе могут быть заменены их наследниками без изменения свойств программы.
  • 12. кот и пес не смогут стать животными :)
  • 14.
  • 15. Interface segregation principle Принцип изоляции интерфейса Много специализированных интерфейсов лучше, чем один универсальный.
  • 16. жирный интерфейс набор тонких специализированных интерфейсов
  • 17.
  • 18. Dependency inversion principle Принцип инверсии зависимостей Зависимости внутри системы строятся на основе абстракций. Модули верхнего уровня не зависят от модулей нижнего уровня. Абстракции не должны зависеть от деталей. Детали должны зависеть от абстракций. а) Модули более высокого уровня не должны зависеть от модулей более низкого уровня. И те и другие должны зависеть только от абстракций. б) Абстракции не должны зависеть от деталей. Детали должны зависеть от абстракций.
  • 20. GRASP General Responsibility Assignment Software Patterns № англ. рус. 1 Information Expert Информационный эксперт 2 Creator Создатель 3 Controller Контроллер 4 Low Coupling Слабая связанность 5 High Cohesion Сильное зацепление 6 Polymorphism Полиморфизм 7 Pure Fabrication Чистая выдумка 8 Indirection Посредник 9 Protected Variations Сокрытие реализации
  • 21. Information Expert Информационный эксперт обязанности должны быть назначены объекту, который владеет максимумом необходимой информации для выполнения обязанности (информационному эксперту). Тривиально, но очень важно!
  • 22.
  • 23. Creator Создатель Это применение шаблона Information Expert к проблеме создания объектов. Класс B должен (может) создавать объекты класса A когда: ● Класс B содержит или агрегирует объекты A. ● Класс B записывает экземпляры объектов A. ● Класс B активно использует объекты A ● Класс B обладает данными инициализации для объектов A.
  • 26. Controller Контроллер Берет на себя ответственность за выполнение операций, приходящих от пользователя. Как правило, не выполняет работу самостоятельно, а делегирует обязанности компетентным объектам. Пример: Model-View-Controller
  • 27.
  • 28. Low Coupling Слабая связанность Распределяет обязанности между объектами таким образом, чтобы степень связанности между системами оставалась низкой. Степень связанности (coupling) — это мера, определяющая, насколько жестко один элемент связан с другими элементами, либо каким количеством данных о других элементах он обладает. Свойства элемента с низкой степенью связанности(слабым связыванием): ● Малое число зависимостей между классами (подсистемами). ● Слабая зависимость одного класса (подсистемы) от изменений в другом классе (подсистеме). ● Высокая степень повторного использования подсистем.
  • 29. High Cohesion Сильное (функциональное) зацепление Задает свойство сильного зацепления внутри подсистемы. Зацепление (cohesion) (функциональное зацепление) — это мера связанности и сфокусированности обязанностей класса. Объект обладает высокой степенью зацепления, если его обязанности тесно связаны между собой и он не выполняет огромных объемов работы. Antipattern: God object
  • 30. Polymorphism Полиморфизм Позволяет обрабатывать альтернативные варианты поведения на основе типа и заменять подключаемые компоненты системы. Все альтернативные реализации приводятся к общему интерфейсу.
  • 31.
  • 32. Pure Fabrication Чистая выдумка Класс, не отражающий никакого реального объекта предметной области, но специально придуманный для усиления зацепления, ослабления связанности или увеличения степени повторного использования.
  • 33.
  • 34. Indirection Посредник Поддерживает слабую связанность путём назначения обязанностей промежуточному объекту. Пример: Model-View-Controller
  • 35. Protected Variations Сокрытие реализации Защищает элементы от изменения других элементов, вынося взаимодействия в фиксированный интерфейс. Поведение может варьироваться лишь с помощью создания другой реализации интерфейса.