Вопросы к зимнему экзамену по ООП
Вопросы по общей теории объектного подхода
НГУ 2018
Список вопросов:
1. Эволюция методологий программирования. Парадигмы программирования.
2. Основные принципы объектного подхода. Абстрагирование.
3. Основные принципы объектного подхода. Инкапсуляция.
4. Основные принципы объектного подхода. Модульность.
5. Основные принципы объектного подхода. Иерархия.
6. Основные принципы объектного подхода. Типизация.
7. Объект с точки зрения ООП. Состояние. Поведение.
8. Объект с точки зрения ООП. Идентичность и жизненный цикл объектов.
9. Объект с точки зрения ООП. Взаимоотношения между объектами.
10. Классы. Природа классов. Метамодель. Инстанцирование.
11. Классы. Структура класса. Абстрактные классы и интерфейсы.
12. Классы. Принцип подстановки Лисковой. Принцип разделения интерфейсов.
13. Классы. Средства UML для построения диаграмм классов.
14. Классы. Отношения между классами. Ассоциация и агрегация.
15. Классы. Иерархии классов. Зависимость.
SRP (Single responsibility principle) - Правило единственности абстракции
Класс должен обладать единственной ответственностью, реализуя ее полностью, реализуя ее хорошо и реализуя только ее. Если объект выполняет множество различных обязанностей — его необходимо распилить. Например, объект печати отчётов ответственен за формат и за содержимое отчётов — это неправильно. За формат должен отвечать один объект, за содержимое — другой.
OCP ( Open/closed principle ) - Принцип открытости/закрытости
Принцип ООП, устанавливающий следующее положение: «программные сущности (классы, модули, функции и т. п.) должны быть открыты для расширения, но закрыты для изменения».
· Открыты для расширения: означает, что поведение сущности может быть расширено путём создания новых типов сущностей.
· Закрыты для изменения: в результате расширения поведения изменения в код не вносятся.
Суть в том, что единожды созданные классы/функции нельзя изменять под конкретные нужды конкретного проекта. Для изменения поведения некоторого класса/функции необходимо явным образом описать его интерфейс и создать другую реализацию этого интерфейса.
LSP ( Liskov Substitution Principle ) - Принцип подстановки Лисков
Методы, принимающие в качестве параметров ссылки на объекты базового класса должны иметь возможность использовать эти объекты без необходимости знать, к базовому или одному из производных они принадлежат т.е. методы определенные в терминах базовых классов должны работать при передаче им в качестве параметров объектов производных классов
(В общем говорит о том, что наследование правильно использовать с целью создания программных иерархий типа общее-частное, но не в кое случае не часть-целое. Пример: колеса у машины — это часть-целое, а «колесо легкового автомобиля» относительно обобщённой сущности «колесо» — является отношением общее-частное).
ISP ( Interface segregation principle ) - Принцип разделения интерфейсов
Клиенты не должны зависеть от интерфейсов, в которых
не нуждаются.
Правильнее использовать множество специализированных интерфейсов, нежели сгруппировывать абсолютно несвязанные между собой методы в общие интерфейсы.
DIP ( Dependency Inversion Principle ) — Принцип инверсии зависимости
Модули высокого уровня не должны зависеть от модулей низкого. И те, и другие, должны зависеть от абстракций.
Например, когда у вас есть класс A, имеющий указатель на класс B — классы считаются сильно связанными. Для замены класса B на любой другой, придётся исправлять код класса A — что не есть хорошо. Предлагается вывести интерфейс класса B, назовем его IB. Изменить тип указателя в классе A на IB. Таким образом зависимость A-->B заменилась на A-->IB<--B. Теперь можно вместо B использовать любую другую реализацию интерфейса IB.
Дополнительно:
Принцип Деметера
Каждый элемент программы должен обладать ограниченным знанием о других элементах и использовать только тесно связанные с ним элементы. Методами, тесно связанными (closely
related) с методом f класса C, называются
• методы класса C
• методы классов, являющихся параметрами f
• методы полей класса C
• методы классов объектов, созданных в f
Парадигмы
· Процедурное программирование – Решите, какие требуются процедуры; используйте наилучшие доступные алгоритмы.
· Модульное программирование – Решите, какие требуются модули; разбейте программу так, чтобы скрыть данные в модулях.
· Объектное программирование – Решите, какие требуются типы; обеспечьте полный набор операций для каждого типа
· ООП – Решите, какие требуются классы; обеспечьте полный набор операций для каждого класса, явно выразите общность через наследование. (Отличие от Объектного программирования - есть наследование)
· Сводная ОО парадигма:
1. Решите какие требуются классы, обеспечьте полный набор операций для каждого класса, выразите общность через наследование (абстракция, инкапсуляция, иерархия)
2. Разбейте систему на сильно связные внутри и слабо связные между собой модули, сгруппируйте абстракции по модулям
3. Используйте наилучшие алгоритмы для реализации методов классов
АССОЦИАЦИЯ
Ассоциация или связь — есть физическое или концептуальное соединение между объектами. Практически это означает, что для того, чтобы объекты могли взаимодействовать друг с другом, между ними должна существовать прямая или косвенная связь. Используя эту связь, объект, являющийся клиентом или инициатором взаимодействия, может вызвать метод (послать сообщение) у сервера — объекта являющегося адресатом взаимодействия, т.е. объект-клиент запрашивает некоторый сервис у объекта-сервера.
· С точки зрения языка программирования, прямая связь означает, что сервер достижим (адресуем) со стороны клиента напрямую с использованием переменной, ссылки или указателя, а так же с использованием «глобальной» видимости.
· Косвенная связь может быть реализована с помощью ассоциативного контейнера, ключа или специального механизма, который может обеспечить в конечном счете доступ от клиента к серверу (т.е. не напрямую, а через посредников).
· Несмотря на то, что взаимодействие является однонаправленным, данные могут передаваться в обоих направлениях (от клиента данные передаются через аргументы при вызове метода, а от сервера данные передаются в возвращаемом методом значении).
При глобальном рассмотрении взаимодействий, можно выделить три основные категории объектов:
· Объекты-актеры — объекты, которые воздействуют на другие объекты, но сами никогда не подвергаются воздействию; это, своего рода, источники всех взаимодействий в системе.
· Объекты-серверы — объекты, которые могут только подвергаться воздействию со стороны других объектов, но никогда не выступающие в роли взаимодействующих объектов; это, своего рода, конечные точки взаимодействий в системе.
· Объекты-агенты — объекты, которые выступают как в активной, так и в пассивной роли; в конечном счете, они являются переносчиками взаимодействий в системе
При локальном рассмотрении взаимодействий, «актеры» всегда выступают в роли клиентов, «серверы» всегда выступают в роли серверов, а «агенты» при взаимодействии для одних объектов являются серверами, а для других — клиентами. При этом, как правило, агент выполняет операции в интересах какого-либо актера или агента.
При рассмотрении взаимодействий клиент-сервер нужно упомянуть еще два важных понятия — видимость и синхронизацию
Видимость:
Для того, чтобы объект-клиент мог вызвать метод объекта-сервера, во-первых, необходимо, чтобы сервер был «видим» для клиента, и во-вторых, клиент должен знать о контракте, предоставляемом сервером.
Информация о контракте задается типом (классом или интерфейсом, т.е. абстракцией) переменной (ссылки, указателя) через которую сервер доступен клиенту. В этом смысле, как мы увидим, при глубоком рассмотрении классов, эта зависимость выражается в семантике абстракций (классов) клиента и сервера.
Всего существует четыре способа обеспечения видимости:
· Сервер имеет глобальную видимость по отношению к клиенту.
· Сервер передан клиенту в качестве параметра операции (метода).
· Сервер является частью клиента.
· Сервер локально порождается клиентом в ходе выполнения какой-либо операции.
В C++ видимость может быть обеспечена с помощью именованных типизированных переменных, ссылок или указателей, которые могут быть глобальными, локальными, статическими, или являться параметрами методов; либо с помощью типизированных вычислимых значений lvalue.
Синхронизация:
Когда клиент посылает сообщение серверу, происходит их синхронизация. В однопоточном приложении синхронизация состоит в запуске метода. Фактически это означает, что в системе существует только один активный объект, поэтому задача разделения доступа к объектам серверам не возникает.
В многопоточной возникает задача обеспечения конкурентного доступа к объекту-серверу со стороны нескольких активных объектов.
Иерархии объектов
Отношение целое – часть.
В отличие от классов, образующих иерархии наследования, объекты образуют агрегационные иерархии. Не следует путать агрегацию классов и агрегацию объектов.
При композиционном отношении между объектами существует зависимость по времени жизни. Так, агрегант (часть) не может существовать без агрегата (целого). При уничтожении объекта-целого, уничтожаются и объекты-части. При ассоциативном отношении объекты могут существовать независимо друг от друга по времени жизни.
Если в программе, написанной на C++, один объект объявлен как обычная (не ссылка и не указатель) переменная (поле) другого объекта, то эти объекты будут находиться в отношении композиции. Связь по времени жизни, в этом случае, обеспечивается самим компилятором (при создание объекта-агрегата будет создан и объект-агрегант; при уничтожении агрегата, агрегант будет уничтожен). В остальных случаях композиция определяется логикой программы.
10. 
Классы. Природа классов. Метамодель. Инстанцирование.
Как мы уже говорили, в основе объектного подхода лежит принцип абстрагирования. Так вот, именно класс является самой важной формой абстракции. С точки зрения программирования, класс является основным кирпичиком при построении объектно-ориентированных программ, позволяя выразить все аспекты связанные как с интерфейсной частью абстракции, так и ее реализацией.
· Класс - множество объектов имеющих общую структуру и поведение.
· Метакласс – класс, экземпляры которого суть классы (Шаблонные классы).
· Объекты - суть экземпляры классов.
По своей природе, класс - это генеральный контракт между абстракцией и всеми ее клиентами.
Метамодель в информатике — модель, описывающая другую модель; транзитивное отношение между двумя моделям (например: если модель M1 описывает язык L0, в котором формулируется модель M0, то M1 является метамоделью М0; если же модель M2 описывает язык L1, в котором была сформулирована модель М1, то М2 — это метамодель M1, а M2 является тогда для M0 мета-метамоделью).
Например, Объекты – модель Реального мира, Классы – метамодель Объектов (т.к. Объекты - модель), UML – метамодель Классов и мета-метамодель Объектов.
* MOF – язык, формально описывающий UML
Инстанцирование, в общем случае, это операция создания элемента модели уровня 
на основе элемента (или группы элементов) модели уровня 
.
· Инстанцирование объектов происходит во время исполнения программы путем выделения памяти и вызова конструктора классов.
· Инстанцирование классов на основе элементов метамодели происходит во
время работы генераторов кода.
· Инстанцирование классов из шаблонов классов происходит во время компиляции программы.
Стрелки в UML
· 
Зависимость обозначает такое отношение между классами, что изменение спецификации класса-поставщика может повлиять на работу зависимого класса, но не наоборот.
· Ассоциация — логическая связь между объектами классов, так, что от объектов одного класса можно перемещаться к объектам другого класса. Бывает однонаправленная, двунаправленная (без стрелочек на концах) и более высокой степени (стрелочки ведут к общему ромбику). Ассоциация может быть именованная, а на концах могут быть написаны роли и прочие свойства.
· Агрегация — это разновидность ассоциации при отношении между целым и его частями. Как тип ассоциации агрегация может быть именованной. Одно отношение агрегации не может включать более двух классов (контейнер и содержимое).
· Композиция — более строгий вариант агрегации. Известна также как агрегация по значению.
· Наследование или «is a» взаимосвязь (или отношение «является») графически представляется линией с пустым треугольником у супертипа.
· Реализация — отношение между двумя элементами модели, в котором один элемент (клиент) реализует поведение, заданное другим (поставщиком). Реализация — отношение целое-часть. Графически реализация представляется так же, как и наследование, но с пунктирной линией. Поставщик, как правило, является абстрактным классом или классом-интерфейсом.
Возле конца стрелки, упирающегося в класс возможно указать кратность (мощность) отношения: 0..1, 1, 0..*, 1..* (понятно, что не имеет смысла для отношений между классами типа наследования, реализации) - означает число связей между каждым экземпляром класса (объектом) в начале линии с экземпляром класса в её конце («один-к-одному», «один-ко-многим», «многие-ко-многим»)
Вопросы к зимнему экзамену по ООП
Вопросы по общей теории объектного подхода
НГУ 2018
Список вопросов:
1. Эволюция методологий программирования. Парадигмы программирования.
2. Основные принципы объектного подхода. Абстрагирование.
3. Основные принципы объектного подхода. Инкапсуляция.
4. Основные принципы объектного подхода. Модульность.
5. Основные принципы объектного подхода. Иерархия.
6. Основные принципы объектного подхода. Типизация.
7. Объект с точки зрения ООП. Состояние. Поведение.
8. Объект с точки зрения ООП. Идентичность и жизненный цикл объектов.
9. Объект с точки зрения ООП. Взаимоотношения между объектами.
10. Классы. Природа классов. Метамодель. Инстанцирование.
11. Классы. Структура класса. Абстрактные классы и интерфейсы.
12. Классы. Принцип подстановки Лисковой. Принцип разделения интерфейсов.
13. Классы. Средства UML для построения диаграмм классов.
14. Классы. Отношения между классами. Ассоциация и агрегация.
15. Классы. Иерархии классов. Зависимость.
SRP (Single responsibility principle) - Правило единственности абстракции
Класс должен обладать единственной ответственностью, реализуя ее полностью, реализуя ее хорошо и реализуя только ее. Если объект выполняет множество различных обязанностей — его необходимо распилить. Например, объект печати отчётов ответственен за формат и за содержимое отчётов — это неправильно. За формат должен отвечать один объект, за содержимое — другой.
Дата: 2019-02-19, просмотров: 566.
