Лекции Java / 03. Типы, их отношения и особенности разработки.pptx

Виды сфокусированности

n По взаимодействию (communication cohesion)

• Части модуля работают над одними и теми же данными

n По последовательности действий

(sequential cohesion)

• Результат работы одной части модуля является исходными данными для другой

n Функциональная (functional cohesion)

•Части модуля направлены на решение одной чёткой задачи, за которую отвечает модуль

Плохой дизайн

•Сложности с пониманием модулей

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

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

Хороший дизайн

Low coupling

High cohesion

nПравда, эти требования друг другу противоречат

nИ следует это из самой природы ООП

nТак что придётся искать компромисс

Принципы SOLID

nSingle responsibility principle

nOpen/closed principle

nLiskov substitution principle

nInterface segregation principle

nDependency inversion principle

Single responsibility principle

n Принцип единственности ответственности

•Каждый класс должен иметь единственную ответственность

•Эта ответственность должна быть полностью инкапсулирована в этом классе

nВсе сервисы класса должны быть направлены исключительно на обеспечение его ответственности

nПринцип обеспечивает высокую сфокусированность

•Класс имеет единственную причину для изменения

•При плохой сфокусированности модификация различных ответственностей приводит к комбинаторному взрыву

Open/closed principle

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

•Новые или изменённые функции требуют создания нового класса

•Рекомендуется наследование реализации

nРеализация используется повторно

nТип не обязан использовать повторно

n Полиморфный принцип открытости/закрытости

•Используются полностью абстрактные типы

•Реализация может быть изменена, или многие реализации могут использоваться полиморфно

•Рекомендуется наследование от полностью абстрактных типов

nТип используется повторно и не изменяется

nРеализации должны соответствовать типу

Liskov substitution principle

n Принцип подстановки Барбары Лисковой

•Пусть q(x) является свойством, верным относительно объектов x некоторого типа T. Тогда q(y) должно быть верным для объектов y типа S, где S является подтипом типа T

•(Р.С. Мартин) Использующие базовый тип функции должны иметь возможность использовать подтипы базового типа не зная об этом

•(Б. Мейер) Дочерний класс не должен нарушать контракт родительского класса

n Требования к сигнатурам операций дочерних классов

•Типы аргументов не должны быть уже

•Типы возвращаемых значений не должны быть шире

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

•Область доступа операции не должна сужаться

Interface segregation principle

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

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

•Интерфейсы должны быть сфокусированными

nБольшие интерфейсы должны разделяться на более мелкие и узкоспециальные

nТакие интерфейсы (полностью абстрактные типы) скорее имеют роль тегов, чем организуют свою иерархию наследования

Dependency inversion principle

n Принцип инверсии зависимостей

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

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

nВысокоуровневые и низкоуровневые компоненты взаимодействуют через абстрактный интерфейс

•Интерфейс описывается как часть высокоуровневого компонента

•Получается, что низкоуровневый компонент зависит от высокоуровневого, а не наоборот

•Это позволяет заменять низкоуровневые компоненты, не изменяя высокоуровневых

nСледование принципу снижает связанность

nЗначительно упрощает разработку сложных систем

Law of Demeter

n Закон Деметры (принцип наименьшего знания)

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

•Каждый модуль должен взаимодействовать только с известными ему модулями и не должен «разговаривать с незнакомыми»

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

nОбъект A может вызвать сервис (метод) объекта B, но не может использовать объект B для получения доступа к объекту C, чтобы использовать его методы

nМетод m() объекта O может вызывать только методы следующих объектов

•Сам объект O

•Объекты-параметры метода m()

•Любые объекты, созданные в ходе выполнения m()

•Объектов, непосредственно ассоциированных с O

•Глобальные переменные, доступные O в контексте m()