Принципы дизайна ПО представляют набор правил, который помогает избежать плохого дизайна. Принципы дизайна объединены Робертом Мартином, кто собрал их в "Agile Software Development: Principles, Patterns, and Practices" (т.е. "Быстрая разработка ПО: Принципы, Паттерны и Практика"). Согласно Роберту Мартину есть 3 важные характеристики плохого дизайна, которые нужно избегать:
Жёсткость - это когда трудно что-либо изменять в коде, так как каждое изменение оказывает воздействие на слишком много других частей системы.
Хрупкость - когда вы делаете изменение, и это приводит к неожиданной поломке других частей системы.
Непереносимость - код трудно повторно использовать в другом приложении, потому что этот код невозможно освободить от имеющегося приложения.
Принцип Открытости-Закрытости (Open Close Principle или OCP)
Программные сущности такие как классы, модули и функции должны быть открыты для расширения, но закрыты для изменений.
OPC является основополагающим принципом. Вы можете обсуждать его, когда пишете ваши классы, чтобы быть уверенными в том, что когда вам будет нужно расширить поведение, вы не должны будете изменять класс, но можете расширять его. Подобный же принцип применим для модулей, пакетов и библиотек. Если у вас есть библиотека, состоящая из множества классов, то есть много причин для того, чтобы вы предпочитали расширение вместо изменения кода, который уже написан (ради обратной совместимости, возвращение к предыдущему тестированию и т.п.). Это причина, по которой мы должны быть уверены, что наши модули следуют Принципу Открытости-Закрытости. По отношению к классам Принцип Открытости-Закрытости может быть гарантированно полезен засчёт использования Абстрактных Классов и конкретных классов для реализации их поведения. Это будет вынуждать иметь Конкретные Классы в качестве расширяющих Абстрактные Классы вместо их изменения. Некоторые частные случаи этого принципа есть Шаблонный Паттерн и Стратегический Паттерн (Template Pattern and Strategy Pattern).
Принцип Инверсии Зависимостей (Dependency Inversion Principle)
Высокоуровеневые модули должны не зависеть от низкоуровневых модулей. Оба должны зависеть от абстракций.
Абстракции не должны зависеть от деталей. Детали должны зависеть от абстракций.
Принцип Инверсии Зависимостей (Dependency Inversion Principle) формулирует, что мы должны отделять высокоуровневые модули от низкоуровневых модулей, вставляя слой абстракции между высокоуровневыми классами и низкоуровневыми классами. Более того этот принцип инвертирует зависимости: вместо написания наших абстракций, основанных на деталях мы должны писать детали, основанные на абстракциях.
Инверсия Зависимостей или Инверсия Контроля являются более понимаемыми терминами если ссылаться на способ, которым эти зависимости реализованы. Классическим способом в ситуации, когда программный модуль (класс, фреймворк, ...) нуждается в каком-нибудь другом модуле, он инициализует и держит прямую ссылку на этот другой модуль. Это приводит к тому, что 2 модуля становятся туго спаренными. Для их разъединения первый модуль будет обеспечиваться хуком, т.е. крючком (свойство, параметр, ...) и внешний модуль контролирующий зависимости будет добавлять ссылку на второй модуль. Засчёт применения Инверсии Зависимостей модули могут быть легко изменяемы другими модулями всего лишь засчёт изменения модуля зависимостей. Фабрики и Абстрактные Фабрики могут быть использованы в качестве фреймворков зависимостей, однако они являются специализированными фрейморками для того, что известно под названием Инверсия Контрольного Контейнера (Inversion of Control Container).
Принцип Отделения Интерфейса (Interface Segregation Principle)
Клиенты не должны принуждаться к зависимости от интерфейсов, которые они не используют.
Этот принцип учит нас заботиться о том, как мы пишем наши интерфейсы. Когда мы пишем интерфейсы, мы должны позаботиться о добавлении только тех методов, которые там должны быть. Если мы добавляем методы, которые не должны быть там, тогда классы реализующие интерфейс будут должны реализовывать эти лишние методы так же как и остальные методы. Например, если мы создаём интрфейс, называемый Worker (Рабочий) и добавляем метод lunch break (обеденный перерыв), тогда все workers (рабочие) будут должны иметь реализацию этого лишнего метода. А что если рабочий оказался роботом?
В качестве умозаключения приходим к тому, что Интерфейсы содержащие методы, которые не специфичны для них, такие методы приводят к тому, что интерфейсы называют загрязнёнными или жирными. Мы должны избегать создания таких интерфейсов.
Принцип Единственной Ответственности (Single Responsibility Principle)
Класс должен иметь только одну причину для изменения.
В этом контексте ответственность рассматривается как единственная причина для изменения. Этот принцип утверждает, что если мы имеем 2 причины для изменения класса, то мы должны разделить функциональность на 2 класса. Каждый класс должен иметь только одну ответственность, и в будущем, если нам будет нужно сделать одно изменение мы собираемся делать это в классе, который которые удерживает эту одну ответственность. Когда нам нужно делать изменения в классе, который имеет больше ответственностей, изменение может оказать воздействие на другую функциональность классов.
Принцип Единственной Ответственности был введён Tom DeMarco в его книге "Structured Analysis and Systems Specification, 1979". Роберт Мартин реинтерпретировал эту концепцию и определил, что ответственность является причиной для изменения.
Принцип Замещения Лискоу (Liskov's Substitution Principle)
Производные типы должны быть способны полностью замещаться их базовыми типами.
Этот принцип есть всего лишь расширение Принципа Открытости-Закрытости в условиях поведения, означающего, что мы должны быть уверены, что новые производные классы являются расширением базовых классов без изменения их поведения. Новые производные классы должны быть способны заменять базовые классы без каких-либо изменений в коде.
Принцип Замещения Лискоу был введён на 1987 Conference on Object Oriented Programming Systems Languages and Applications, in Data abstraction and hierarchy.
Last Updated ( Thursday, 27 March 2008 )
Перевод на русский язык Мурата Джусупова
Оригинальный текст на английском языке взят из http://www.oodesign.com/design-principles.html
Оригинальный текст на английском языке взят из http://www.oodesign.com/design-principles.html
Комментариев нет:
Отправить комментарий