22. Объектно-ориентированные анализ и проектирование программных систем. Основные определения.

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

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

1. данные, называемые атрибутами (поля) – определяют структуру объекта. Значения атрибутов определяют состояние объекта.

2. объектные связи (разновидность атрибутов) – обозначают знания данным объектом других объектов (ассоциация).

3. процедуры и функции – представляют собой предоставляемые объектом услуги (методы или службы). методы определяют поведение объекта, изменяют состояние объекта или заставляют объект отправить объект отправить сообщение другим объектам.

4. правила, которые устанавливают взаимосвязи свойств объекта или определяют условия его жизнеспособности (инварианты класса).

Объекты разных видов могут реагировать на одно и то же сообщение по разному, но при этом должны выдавать результаты одного и того же типа. Такое поведение объектов называется полиморфным.

Обычно атрибуты делают закрытыми (приватными) и для доступа реализуют методы set и get. Объекты, которые имеют только атрибуты и методы set/get/конструкторы называются немыми. Если большинство объектов немые, то программа не объектно-ориентированная.

Особенности объекта:

1. имя, по которому его можно отличить от других объектов;

2. одно или несколько состояний, включающих в себя имена атрибутов или значения атрибутов в определенной момент времени;

3. объект обладает поведением, которое определяется его методами.

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

23. Основные принципы объектно-ориентированной разработки программ.

Ключевые принципы ООП:

1. все является объектами (не всегда можно соблюдать из-за ограничений языков, требований предметной области и т.д.).

2. вычисления осуществляются путем пересылки сообщений между объектами. Объекты взаимодействуют посылая и принимая сообщения. Сообщение – некий запрос на выполнение действия, как правило содержит набор аргументов, которые могут понадобится для выполнения действий.

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

Принципы объектно-ориентированной методологии.

SOLID – аббревиатура 5 основных принципов проектирования классов в ООМ:

1. SRP (Single responsibility principle) – принцип единственной обязанности (одиночной ответственности) – на каждый объект системы должна быть возложена одна единственная обязанность. (обязанность – причина изменения объекта). Этот принцип основан на принципе высокой связности. Нарушение этого принципа – God object.

2. OCP (Open/closed principle) – принцип открытости/закрытости – программные сущности (классы, модули, функции и т.д.) должны быть открыты для расширения но закрыты для изменения. Нарушение – использование конкретных классов (объектов) без абстракции.

3. LSP (Liskov substitution principle) – принцип подстановки Барбары Лисков – объекты в программе могут быть заменены их наследниками без изменения свойств программы (функции, которые использует базовый тип, должны иметь возможность использовать подтипы базового типа не зная об этом).

4. ISP (Interface segregation principle) – принцип разделения интерфейса – множество специализированных интерфейсов лучше чем один универсальный. Клиенты (классы) не должны зависеть от методов, которые они не используют.

5. DIP (Dependency inversion principle) – принцип инверсии зависимостей:

• модули верхних уровней не должны зависеть от модулей нижних уровней, модули обоих уровней должны зависеть от абстракций;

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

Нарушения:

• жесткость – изменение одного модуля ведет к изменению других;

• хрупкость – изменения в модулях ведут к неконтролируемым ошибкам в других частях программы;

• неподвижность – модуль очень сложно отделить от остальной части приложения для повторного использования.