Объектно-ориентированное программирование. Отношения между типами и особенности разработки. (Занятие 11)
Содержание
- 2. План лекции Отношения между классами Объектно-ориентированный дизайн Принципы дизайна
- 3. Отношения между классами Наследование Зависимость Ассоциация Агрегация Композиция Метакласс
- 4. Особенности Использование одним классом структуры и/или поведения другого класса Дочерний класс специализирует родительский класс Образуется отношение
- 5. Особенности Изменение в одном классе (независимом) может влиять на другой класс (зависимый) Зависимый класс как-то использует
- 6. Особенности Семантическая связь классов Мощность Один к одному Один ко многим Многие к одному Многие ко
- 7. Особенности Можно считать частным случаем ассоциации Образуется отношение «целое-часть» между объектами Агрегат (контейнер) – большой внешний
- 8. Особенности Можно считать частным случаем агрегации Время жизни объектов-частей определяется объектом-контейнером и не может превышать время
- 9. Особенности Метакласс – это класс, объектами которого являются классы Корневой метакласс – единственный объект, являющийся своим
- 10. Ещё одна проблема разработки программ в ООП Этапы разработки (условно) Определение модели данных Определение алгоритма в
- 11. Object-oriented design Объектно-ориентированное проектирование – планирование системы как совокупности взаимодействующих объектов с целью решения программной задачи
- 12. Характеристики дизайна Coupling (связанность, зависимость) Характеристика взаимосвязи модулей Степень того, насколько модуль зависит от других модулей
- 13. Виды связанности Связанность содержимого (content coupling)- Один модуль изменяет или полагается на внутренние особенности другого модуля
- 14. Виды связанности Связанность через внешнее (external coupling) Два модуля используют навязанный извне формат данных, протокол связи
- 15. Виды связанности Связанность по структурированным данным (data-structured coupling, stamp coupling) Модули используют одну и ту же
- 16. Виды связанности Связанность по сообщениям (message coupling) Модули общаются только через передачу параметров или сообщений Состояние
- 17. Виды сфокусированности Случайная (coincidental cohesion) Части модуля сгруппированы «от фонаря» Единственное, что их объединяет – сам
- 18. Виды сфокусированности По взаимодействию (communication cohesion) Части модуля работают над одними и теми же данными По
- 19. Плохой дизайн Высокая связанность Эффект кругов по воде (или снежной лавины) при внесении изменений Сборка модулей
- 20. Хороший дизайн Loose coupling High cohesion Правда, эти требования друг другу противоречат И следует это из
- 21. Принципы SOLID Single responsibility principle Open/closed principle Liskov substitution principle Interface segregation principle Dependency inversion principle
- 22. Принципы SOLID http://lostechies.com/derickbailey/2009/02/11/solid-development-principles-in-motivational-pictures/
- 23. Single responsibility principle Принцип единственности ответственности Каждый класс должен иметь единственную ответственность Эта ответственность должна быть
- 24. Single responsibility principle public class Service{ public static Image getImage(String fileName) { ... } public static
- 25. Single responsibility principle public class ImageService{ public static Image getImage(String fileName) { ... } public static
- 26. Single responsibility principle
- 27. Open/closed principle Принцип открытости/закрытости Программные сущности (классы, модули и т.п.) должны быть открыты для расширения, но
- 28. Open/closed principle public class MessageSender { ... public void send(Message msg) { if(msg.getType == MessageType.SMS) sendSMS(msg);
- 29. Open/closed principle public class MessageSender { ... public void send(Message msg){ msg.send(); } ... } public
- 30. Open/closed principle
- 31. Liskov substitution principle Принцип подстановки Барбары Лисковой Пусть q(x) является свойством, верным относительно объектов x некоторого
- 32. Liskov substitution principle public class Rectangle{ double height, width; // методы set и get } public
- 33. Liskov substitution principle public class Square extends Rectangle{ public void setHeight(double h) {height = width =
- 34. Liskov substitution principle
- 35. Interface segregation principle Принцип разделения интерфейсов Клиенты не должны зависеть от методов, которые они не используют
- 36. Interface segregation principle
- 37. Dependency inversion principle Принцип инверсии зависимостей Модули верхних уровней не должны зависеть от модулей нижних уровней.
- 38. Dependency inversion principle public class Man { private Car car; public void gotoWork() { car =
- 39. Dependency inversion principle public class Man { private Mode mode; public void setModeOfMovement(Mode newMode) { this.mode
- 40. Dependency inversion principle
- 41. Law of Demeter Закон Деметры (принцип наименьшего знания) Каждый модуль должен обладать ограниченным знанием о других
- 42. Принцип YAGNI You ain’t gonna need it Реализуйте что-то, только если оно вам действительно нужно Не
- 43. Принцип KISS Keep it simple, stupid Keep it simple and stupid Keep it short and simple
- 44. Спасибо за внимание!
- 46. Скачать презентацию