МЕТОДИ ОБ'ЄКТНО- ОРІЄНТОВАНОГО ПРОГРАМУВАННЯ Бублик В.В. Кафедра мультимедійних систем, кімн. 204/1 Консультації: середа, год. You are welcome! Copenhagen, Zodiac

© 2006 Бублик В.В. МООП. 5. Вкладення (layering) обєктів2 (35) Тема 4. Вкладення об'єктів Object layering 1.Інкапсуляція: композиція і агрегація 2.Ідіома вмісту і реалізації 3.Агрегація відсилками і указниками 4.Асоціація

Інкапсуляція Як і з чого збирати об'єкти? – Повторити трикутники

© 2006 Бублик В.В. МООП. 5. Вкладення (layering) обєктів4 (35) Проектування структури класу Визначення узгоджених абстракцій: будинок складається з вікон, дверей, стін, перекриттів, тощо, а не з дошок, цегли і цвяхів Збалансована інкапсуляція: знаємо, що будинок має двері, але не знаємо, з чого вони складаються Приховування інформації: зменшення складності і локалізація можливих змін

© 2006 Бублик В.В. МООП. 5. Вкладення (layering) обєктів5 (35) Спряження класів Слабке Через параметр POD (Plain Old Data) Створення об'єкту Через об'єкт-параметр Стабільне Ієрархічне Жорстке (уникаємо) Семантичне

© 2006 Бублик В.В. МООП. 5. Вкладення (layering) обєктів6 (35) Зниження жорсткості спряжень Закриття доступу до атрибутів, неінтерфейсних методів, службових класів Мінімізація кола друзів Зменшення порушень інкапсуляції Скорочення захищених атрибутів Дотримання правила Деметри

© 2006 Бублик В.В. МООП. 5. Вкладення (layering) обєктів7 (35) Правило Деметри Дозволено: Виклик власного методу Виклик методу свого компоненту Заборонено: Виклик методу об'єкту, створеного компонентом Деметра – богиня родючості. Аїд з дозволу Зевса викрав її дочку Персифону

Композиція: ідіома вмісту Клас складається із своїх атрибутів Об'єкт володіє своїми атрибутами

© 2006 Бублик В.В. МООП. 5. Вкладення (layering) обєктів9 (35) Композит //Компонент неявно створюється //і видаляється композитом class Composite { private: Component c; };

© 2006 Бублик В.В. МООП. 5. Вкладення (layering) обєктів10 (35) Компонент class Component { public: Component(int n=1):id(n){} ~Component(){} private: int id; };

© 2006 Бублик В.В. МООП. 5. Вкладення (layering) обєктів11 (35) Атрибут-указник (все ще композиція) class Composite { public: Composite(int); ~Composite(); private: Component *pc; };

© 2006 Бублик В.В. МООП. 5. Вкладення (layering) обєктів12 (35) Створення/видалення //Компонент явно створюється //і видаляється композитом Composite :: Composite(int n): pc(new Component(n)){}; Composite :: ~Composite() { delete pc };

© 2006 Бублик В.В. МООП. 5. Вкладення (layering) обєктів13 (35) Висновок 1 (про композицію) Атрибути, виражені указниками, можуть (але не мусять) розглядатися як компоненти, якщо вони не знаходяться у спільному використанні, а композит відповідає за їх створення і видалення

© 2006 Бублик В.В. МООП. 5. Вкладення (layering) обєктів14 (35) Висновок 2 (про композицію) Атрибути спільного використання можуть трактуватися як компоненти за умови їх агрегації за допомогою інтелектуальних указників

© 2006 Бублик В.В. МООП. 5. Вкладення (layering) обєктів15 (35) Висновок 3 (про композицію) Композиція об'єктів вимагає явно визначеного або повністю забороненого копіювання Примітка. В контейнерах завжди розміщуйте самі об'єкти або їх маніпулятори

© 2006 Бублик В.В. МООП. 5. Вкладення (layering) обєктів16 (35) Використання зовнішніх ресурсів Ідіома RAII Resource Acquisition Is Initialization Придбанням ресурсу служить (його) ініціалізація Відкрили (захопили) файл, порт, інший ресурс Хто його закриє (відпустить)?

© 2006 Бублик В.В. МООП. 5. Вкладення (layering) обєктів17 (35) Приклад використання ресурсів class Port { public: Port(const string& dst);//openPort ~Port();//closePort }; int main () { Port port(server311:8000); }//порт закриється деструктором

Агрегація: ідіома реалізації Агрегати реалізуються за допомогою своїх компонент

© 2006 Бублик В.В. МООП. 5. Вкладення (layering) обєктів19 (35) Залежності компіляції: сильні //Компіляція композиту вимагає //приєдання визначення компонент #include Component.h class Composite { private: Component c; };

© 2006 Бублик В.В. МООП. 5. Вкладення (layering) обєктів20 (35) Залежності компіляції: слабкі //Клас Agregee використовується //для реалізації класу Agregate: //досить упередженого оголошення class Agregee; class Agregate { private: Agregee * pagr; };

© 2006 Бублик В.В. МООП. 5. Вкладення (layering) обєктів21 (35) Відокремлення реалізації class Person { public: Person(const string&, const Date&); virtual ~Person(); string name() const; private: string _name; // implementation detail Date _birthDate; // implementation detail };

© 2006 Бублик В.В. МООП. 5. Вкладення (layering) обєктів22 (35) Конверт (клас-дескриптор) class PersonImpl { public: PersonImpl(const string&, const Date&); virtual ~PersonImpl(); string name() const; private: string _name; // implementation detail Date _birthDate; // implementation detail };

© 2006 Бублик В.В. МООП. 5. Вкладення (layering) обєктів23 (35) Лист (тіло) class PersonImpl; class Person { public: Person(const string&, const Date&); virtual ~Person(); string name() const; private: PersonImpl *_impl;//ptr to implementation };

© 2006 Бублик В.В. МООП. 5. Вкладення (layering) обєктів24 (35) Реалізація Person::Person (const string& nm, const Date& bd): _impl(new PersonImpl (nm, bd) ) {}; string Person::name() const { return _ipml->name(); };

© 2006 Бублик В.В. МООП. 5. Вкладення (layering) обєктів25 (35) Прихована реалізація // Anything.h struct HiddenImpl; class Anything { public:……………………………. private: HiddenImpl *pimpl; };

© 2006 Бублик В.В. МООП. 5. Вкладення (layering) обєктів26 (35) Схованка // Anything.cpp #include Anything.h struct HiddenImpl { // Everything you have to hide ……………………………………. }; //Further implementation

© 2006 Бублик В.В. МООП. 5. Вкладення (layering) обєктів27 (35) Агрегація відсилками Тільки в дуже обмеженому контексті: неконтрольоване спільне використання (Пригадайте: трикутник, відрізок, точка)

Асоціація Використання одного об'єкту іншим

© 2006 Бублик В.В. МООП. 5. Вкладення (layering) обєктів29 (35) Варіанти асоціації Передача параметрів значенням Передача параметрів відсилками Передача параметрів указниками Знайомства: існування в спільній області дії (наприклад, в тілі функції)

© 2006 Бублик В.В. МООП. 5. Вкладення (layering) обєктів30 (35) Уникаємо семантичних обмежень Управляючі параметри void f(bool flag, …) { if (flag) ………… Глобальне управління bool flag

© 2006 Бублик В.В. МООП. 5. Вкладення (layering) обєктів31 (35) Уникаємо семантичних обмежень Глобальне управління bool gFlag; void f1(…) { gFlag = true;……… void f (…) { if (gFlag) …………

© 2006 Бублик В.В. МООП. 5. Вкладення (layering) обєктів32 (35) Уникаємо семантичних обмежень Припущення ініціалізації class AnyClass { void initialize(…); void run(…);//calls initialize() }; AnyClass any; //any.initialize(); any.run();

© 2006 Бублик В.В. МООП. 5. Вкладення (layering) обєктів33 (35) Уникаємо семантичних обмежень Припущення використання class AnyClass { AnyClass (a,b,…,c,u,v,…,w); AnyClass (a,b,…,c); }; f(AnyClass(A,B,…,C,U,V,…,W)); g(AnyClass(A,B,…,C));

© 2006 Бублик В.В. МООП. 5. Вкладення (layering) обєктів34 (35) Уникаємо семантичних обмежень Припущення підкласу class Derived : public Base{…}; void f(const Base& object) { Derived & derived = dynamic_cast (object); derived.derivedMethod();………

© 2006 Бублик В.В. МООП. 5. Вкладення (layering) обєктів35 (35) Висновки Проектуючи класи, визначайте ієрархії, зокрема їх вплив на тривалість життя об'єктів Спирайтеся лише на інтерфейс і не покладайтеся на знайомства між класами