1. Основи об’єктно-орієнтованого
програмування

2. ООП є інструментом розробки ПЗ
(одним із багатьох)
The Right Way: вміти користуватись кількома
інструментами в залежності від потреб
Мета сьогодні: сформувати «відчуття» ООП

3. Програмне забезпечення
• Успішне
– Legacy (унаслідуване, застаріле)
– Maintainable (легко підтримуване)
• Неуспішне

4. Legacy software
• Довго експлуатується
• Продовжує експлуатуватись
• Задовільняє потреби замовника
• Але разом з тим
– Містить дефекти, не містить нових функцій 
• Важко покращується

5. Maintainable software
• Довго експлуатується
• Продовжує експлуатуватись
• Задовільняє потреби замовника
• Але разом з тим
– Містить дефекти, не містить нових функцій
• Легко покращується

6. Неуспішне ПЗ
• Непередбачувано короткий цикл життя
• Не задовільняє потреб замовника
• Якість не має значення

7. Легке покращення
• Хочемо змінювати програму
– Проясняються старі/з’являються нові вимоги
• Не хочемо змінювати готовий код
– Зміна – внесення нестабільності
– Потрібно перетестувати
– Залежності транзитивні

8. Складність
• Розробка ПЗ – управління складністю
QuickSort NULL
Apologized
Tony Hoare:
There are two ways of constructing a software design:
One way is to make it so simple that there are
obviously no deficiencies,
and the other way is to make it so complicated that
there are no obvious deficiencies.
The first method is far more difficult.

9. Складність
• Способи зменшення складності:
– Підвищення IQ - ?
– Декомпозиція
– Абстрагування
– Перевикористання
–…

10. Structured programming
• if, while, functions замість goto
• Краще розуміння того, що робить програма
• За рахунок абстрактніших конструкцій
• Мета – уникнути «спагетті-коду»
• Bad news: самої парадигми виявилось
недостатньо
• Непідтримуваний код все ще можливий

11. Object-oriented
• Об’єкти замість процедур
• Краще розуміння того, що робить програма
• За рахунок абстрактніших конструкцій
• Мета – уникнути «спагетті-коду»
• Bad news: самої парадигми виявилось
недостатньо
• Непідтримуваний код все ще можливий

12. Мета ООП
Knitted castle vs Lego castle
http://www.amazon.com/Knit-Enchanted-
Castle-Jan-MESSENT/dp/085532600X

13. ООП
• Набір об’єктів, що взаємодіють між собою
(object graph)
• Об’єкти моделюють поняття з
– Області задачі (problem domain)
– Області реалізації (implementation domain)

14. Over-engineered HelloWorld
• Приклад ООП стилю
• Не приклад доцільності ООП
• Взаємодіють між собою об’єкти
• Класи описують об’єкти (дані та операції)
• У об’єкта є 2 типи клієнтів:
– Внутрішні (сам об’єкт)
– Зовнішні
– Плюс ще наслідування реалізації
• Об’єкти можуть мати явно виділений
інтерфейс

15. Що видно з прикладу?
Абстракція
– Всі класи
Інкапсуляція
– Всі класи
– SecureMessageWriter
Наслідування інтерфейсу
– MessageWriter
Поліморфізм (subtype polymorphism)
– Метод MessageWriter.write()

16. Абстракція
Ігнорування несуттєвих деталей
щоб сфокусуватись на важливому на даний момент
Рівні абстракції (abstraction layers)
низький  високий
Абстракція даних data abstraction
Абстракція керування control abstraction

17. Інкапсуляція

18. Інкапсуляція
Захищається цілісність об’єкту: об’єкт
неможливо перевести у невірний стан
Приховується реалізація об’єкту
Інформація доступна через методи
Об’єкт об’єднує дані та методи роботи з
даними

19. Object-oriented word-wrap
• Приклад моделі задачі
• Можливих моделей може бути кілька
• Модель містить як сутності з області задачі,
так і сутності з області реалізації
• Абстрагування від деталей реалізації

20. Синтаксичні конструкції
• сlass: описує структуру і поведінку об’єктів
• Конструктор
• Поля
• Методи
• Модифікатори доступу: public, private
• Інтерфейс: virtual void method() = 0;
• Наслідування інтерфейсу: class C : public I{}

21. • ООП є лише одним із інструментів
• ООП не є оптимальним для всіх випадків
• але:
краще недоцільна якісна реалізація,
ніж доцільна неякісна
• Тому існують мультипарадигменні мови