Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

SOLID & GRASP

13,579 views

Published on

  • Вот немного материалов (помимо Википедии), из которых компилировал:
    http://www.doolwind.com/blog/solid-principles-for-game-developers/
    http://habrahabr.ru/blogs/complete_code/92570/
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here

SOLID & GRASP

  1. 1. SOLID GRASPосновные принципы ООП
  2. 2. 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 зависимостей
  3. 3. Single responsibility principle Принцип единственной обязанностиНа каждый объект должна быть возложена одна единственная обязанность.
  4. 4. смешенная ответственностьразделенная ответственность
  5. 5. Open/closed principle Принцип открытости/закрытостиПрограммные сущности должны быть открыты для расширения, но закрыты для изменения.
  6. 6. открытая "кухня"закрытая "кухня"
  7. 7. Liskov substitution principle Принцип подстановки Барбары Лисков Объекты в программе могут быть заменены ихнаследниками без изменения свойств программы.
  8. 8. кот и пес не смогут стать животными :)
  9. 9. треугольник может стать фигурой
  10. 10. Interface segregation principle Принцип изоляции интерфейсаМного специализированных интерфейсов лучше, чем один универсальный.
  11. 11. жирный интерфейснабор тонких специализированных интерфейсов
  12. 12. Dependency inversion principle Принцип инверсии зависимостей Зависимости внутри системы строятся на основе абстракций. Модули верхнего уровня не зависят от модулей нижнего уровня. Абстракции не должны зависеть от деталей. Детали должны зависеть от абстракций.а) Модули более высокого уровня не должны зависеть от модулей более низкого уровня. И те и другие должны зависеть только от абстракций.б) Абстракции не должны зависеть от деталей. Детали должны зависеть от абстракций.
  13. 13. сильная зависимостьслабая зависимость
  14. 14. GRASPGeneral 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 Сокрытие реализации
  15. 15. Information Expert Информационный эксперт обязанности должны быть назначены объекту, который владеет максимумомнеобходимой информации для выполненияобязанности (информационному эксперту). Тривиально, но очень важно!
  16. 16. Creator Создатель Это применение шаблона Information Expert к проблеме создания объектов.Класс B должен (может) создавать объекты класса A когда:● Класс B содержит или агрегирует объекты A.● Класс B записывает экземпляры объектов A.● Класс B активно использует объекты A● Класс B обладает данными инициализации для объектов A.
  17. 17. Abstract FactoryАбстрактная фабрика
  18. 18. BuilderСтроитель
  19. 19. Controller Контроллер Берет на себя ответственность за выполнение операций, приходящих от пользователя. Как правило, не выполняет работусамостоятельно, а делегирует обязанности компетентным объектам.Пример: Model-View-Controller
  20. 20. Low Coupling Слабая связанностьРаспределяет обязанности междуобъектами таким образом, чтобы степеньсвязанности между системами оставаласьнизкой.Степень связанности (coupling) — это мера, определяющая, насколькожестко один элемент связан с другими элементами, либо какимколичеством данных о других элементах он обладает.Свойства элемента с низкой степенью связанности(слабым связыванием):● Малое число зависимостей между классами (подсистемами).● Слабая зависимость одного класса (подсистемы) от изменений в другом классе (подсистеме).● Высокая степень повторного использования подсистем.
  21. 21. High Cohesion Сильное (функциональное) зацепление Задает свойство сильного зацепления внутри подсистемы.Зацепление (cohesion) (функциональное зацепление) — это мерасвязанности и сфокусированности обязанностей класса.Объект обладает высокой степенью зацепления, еслиего обязанности тесно связаны между собой и он невыполняет огромных объемов работы.Antipattern: God object
  22. 22. Polymorphism Полиморфизм Позволяет обрабатывать альтернативные варианты поведения на основе типа и заменять подключаемые компоненты системы.Все альтернативные реализации приводятся к общемуинтерфейсу.
  23. 23. Pure Fabrication Чистая выдумка Класс, не отражающий никакого реальногообъекта предметной области, но специально придуманный для усиления зацепления, ослабления связанности или увеличения степени повторного использования.
  24. 24. Indirection Посредник Поддерживает слабую связанность путём назначения обязанностей промежуточному объекту.Пример: Model-View-Controller
  25. 25. Protected Variations Сокрытие реализацииЗащищает элементы от изменения других элементов, вынося взаимодействия в фиксированный интерфейс.Поведение может варьироваться лишь с помощью создания другой реализации интерфейса.

×