Поняття компонента, компонентної моделі, компонентно-орієнтованого програмування

Назва роботи: Поняття компонента, компонентної моделі, компонентно-орієнтованого програмування

Предметна область: Інформатика, кібернетика та програмування

Опис: Що являє собою компонент Компонент від лат. У програмуванні компонент це цеглинка програми складається з властивостей properties методів methods і подій events. Властивості дають можливість управляти виглядом і поведінкою компонента методи використовувати можливості надані компонентом а події реагувати на що відбуваються всередині компонента події програмувати реакцію компонента на зовнішні події і т.

Розмір файлу: 61 KB

Роботу скачали: 43 чол.

Поняття компонента, компонентної моделі, компонентно-орієнтованого програмування

1. Що являє собою компонент

Компонент (від лат. З omponent - що становить) - складова частина, елемент чогось. У програмуванні компонент # 151; це "цеглинка" програми, що складається з властивостей (properties), методів (methods) і подій (events). Властивості дають можливість управляти виглядом і поведінкою компонента, методи # 151; викорис? зувати можливості, що надаються компонентом, а події # 151; реагувати на що відбуваються всередині компонента події, програмувати реакцію компонента на зовнішні події і т. д.

Розробка програми за допомогою компонентів називається компонентно-орієнтованим програмуванням.

Почнемо з визначення терміна компонент в програмуванні. компонент # 151; це незалежний модуль, призначений для багаторазового використання та надається користувачеві в довічним форматі. Це визначення описує чотири ключових характеристики компонента. Розглянемо їх по черзі.

Компонент визначено як незалежний модуль. Це означає, що кожен компонент цілком самодостатній. Іншими словами, компонент забезпечує повний набір функцій. Його внутрішня робота закрита для "зовнішнього світу", але при цьому реалізація може бути змінена без наслідків для коду, в якому використовується цей компонент.

Компонент призначений для багаторазового застосування. Це означає, що компонент може використовувати будь-яка програма, якій потрібні його функції. Програма, яка використовує компонент, називається клієнтом. Таким чином, компонент може працювати з будь-якою кількістю клієнтів.

Компонент являє собою окремий модуль. Це дуже важливо. З точки зору клієнта компонент виконує конкретну функцію або набір функцій. Функціями компонента, може скористатися будь-який додаток, але сам компонент не є автономною програмою.

Нарешті, компонент повинен бути представлений в довічним форматі. Це принципово важливо. Хоча використовувати компонент можуть багато клієнтів, вони не мають доступу до його вихідного коду. Функціональність компонента відкрита для клієнтів тільки за допомогою його public-членів. Іншими словами, саме компонент керує тим, які функції залишати відкритими для клієнтів, а які # 151; тримати "під замком".

2. Компонентна модель

Принципово велике значення також має модель, яка реалізує компоненти. Для того щоб клієнт міг використовувати компонент, необхідно, щоб і клієнт, і компонент використовували один і той же набір правил. Набір правил, що визначають форму і поведінку компонента, і називається компонентної моделлю. Саме компонентна модель визначає характер взаємодії компонента і моделі. Компонентна модель важлива хоча б тому, що призначений для багаторазового використання компонент, надається користувачеві в довічним форматі, може бути реалізований різними способами, причому кількість цих способів може бути дуже великим. Наприклад, існує безліч різних способів передачі параметрів і прийому значень. Можна також по-різному виділяти (і звільняти) пам'ять (і інші системні ресурси) для об'єктів. Тому для ефективного використання компонентів клієнти і самі компоненти повинні підкорятися правилам, визначеним компонентної моделлю. По суті, компонентна модель являє свого роду контракт між клієнтом і компонентом, який обидві сторони згодні виконувати.

До створення С # і середовища. NET Framework більшість компонентів були СОМ-компонентами. Модель СОМ була розроблена для традиційного середовища Windows і мови С ++. Тому вона в принципі не в змозі використати переваги нових методів управління пам'яттю, які реалізовані в С # і. NET Framework. Як наслідок, СОМ-контракт був досить важким для реалізації і ненадійним. На щастя, С # і середовище. NET Framework позбавлені практично всіх проблем своїх попередників.

3. Що являє собою С # -компонент

Завдяки особливостям роботи засобів мови С #, будь-який його клас повністю відповідає загальному визначенню компонента. Наприклад, будучи скомпільований, клас (в його двійковій формі) можна використовувати в різних додатках. Але чи означає це, що будь-який клас є компонентом? Відповідь: ні. Для того щоб клас став компонентом, він повинен слідувати компонентної моделі, певним середовищем. NET Framework. На щастя, цього зовсім не важко домогтися: такий клас повинен реалізувати інтерфейс System. ComponentModel. IComponent. При реалізації інтерфейсу IComponent компонент задовольняє набору правил, що дозволяють компоненту бути сумісним із середовищем. Framework.

Незважаючи на простоту реалізації інтерфейсу IComponent. у багатьох ситуаціях краще використовувати альтернативний варіант - клас System. ComponentModel. Component. Клас Component забезпечує стандартну реалізацію інтерфейсу IComponent. Він також підтримує інші корисні засоби, властиві компонентам. Досвід показує, що більшості творців компонентів зручніше виводити їх з класу Component. ніж самим реалізувати інтерфейс IComponent. оскільки в першому випадку потрібно просто менше програмувати. Отже, в С # на створення компонента не потрібно "героїчних зусиль" з боку програміста.

4. Контейнери та вузли

З С # -компонента тісно пов'язані дві інші конструкції: контейнери і вузли.

контейнер # 151; це група компонентів. Контейнери спрощують програми, в яких використовується безліч компонентів.

Вузол може пов'язувати компоненти і контейнери.

5. Інтерфейс IComponent

Інтерфейс IComponent визначає правило, якого повинні дотримуватися всі компоненти. В інтерфейсі IComponent визначено тільки одна властивість і одна подія. Ось як оголошується властивість Site.

Властивість Site отримує або встановлює вузол компонента. Вузол ідентифікує компонент. Це властивість має null-значення, якщо компонент не зберігається в контейнері.

Подія, визначена у інтерфейсі IComponent. носить ім'я Disposed і оголошується так:

event EventHandler Disposed

Клієнт, якому потрібно отримати повідомлення при руйнуванні компонента, реєструє обробник подій за допомогою події Disposed. Інтерфейс IComponent також успадковує інтерфейс System. IDisposable. в якому визначено метод Dispose ():

Цей метод звільняє ресурси, використовувані об'єктом.

6. Клас Component

Незважаючи на те що для створення компонента досить реалізувати інтерфейс IComponent. набагато простіше створити клас, похідний від класу Component. оскільки він реалізує інтерфейс IComponent за замовчуванням. Якщо клас успадковує клас Component. значить, він автоматично виконує правила, необхідні для отримання. NET -Сумісність компонента.

У класі Component визначено конструктор тільки за замовчуванням. зазвичай
програмісти не створюють об'єкт класу Component безпосередньо, оскільки основне призначення цього класу # 151; бути базовим для створюваних компонентів.

public IContainer Container

Властивість Container повертає контейнер, який містить викликає компонент. Якщо компонента немає в контейнері, повертається значення null. Слід пам'ятати, що властивість Container встановлюється компонентом, а контейнером.

Друге властивість, Site. визначено в інтерфейсі IComponent. У класі Component воно реалізовано як віртуальне:

public virtual ISite Site

Властивість Site повертає або встановлює об'єкт типу ISite. пов'язаний з компонентом. Воно повертає значення пі11, якщо компонента в контейнері немає. Властивість Site встановлюється компонентом, а контейнером.

У класі Component визначено два відкритих методу. Перший являє собою перевизначення методу ToString (). Другий, метод Dispose (). використовується в двох формах. Перша з них така:

public void Dispose ();

Метод Dispose (), викликаний в першій формі, звільняє будь-які ресурси, використовувані викликає компонентом. Цей метод реалізує метод Dispose (), визначений в інтерфейсі System. IDisposable. Для звільнення компонента і займаних їм ресурсів клієнт викликає саме цю версію методу Dispose ().

Ось як виглядає друга форма методу Dispose ().

protected virtual public void Dispose (bool how);

Якщо параметр how має значення true. ця версія методу звільняє як керовані, так і некеровані ресурси, використовувані викликає об'єктом.

Якщо how дорівнює значенню false. звільняються тільки некеровані ресурси. Оскільки ця версія методу Dispose () захищена (protected), її не можна викликати з коду клієнта. Тому клієнт використовує першу версію. Іншими словами, виклик першої версії методу Dispose () генерує звернення до методу Dispose (bool how).

У загальному випадку компонент, в якому більше немає необхідності, переопределяет версію Dispose (bool how), якщо він містить ресурси, які потрібно звільнити. Якщо компонент не займає ніяких ресурсів, то для його звільнення досить стандартною реалізації методу Dispose (bool how), визначеної в класі Component.

Клас Component успадковує клас MarshalByRefObject. який використовується в тому випадку, коли компонент створюється поза локальної середовища, наприклад в іншому процесі або на іншому комп'ютері, пов'язаному з першим по мережі. Для обміну даними (аргументами методів і повертаються значеннями) повинен існувати механізм, який визначить спосіб пересилання даних. За замовчуванням приймається, що інформація повинна передаватися за значенням, але при успадкуванні класу MarshalByRefObject дані будуть передаватися по посиланню. Таким чином, С # -компонент забезпечує передачу даних по посиланню.

7. Компоненти: переваги і недоліки

Компонентно-орієнтована розробка має свої сильні і слабкі сторони. Безперечними перевагами є повторна використовуванність до? Да, узгодженість призначеного для користувача інтерфейсу, можливість швидкої і продуктивної розробки програм. Саме компоненти дозволяють про? Граммістам складати кінцевий продукт з "цеглинок", не вдаючись у деталі реалізації конкретного компонента. Звичайно, набори класів, що використовуються при об'єктно-орієнтованому підході, теж дають можливість повторного використання коду, але компоненти роблять повторне використання коду абсолютно природним.

Якщо при розробці системи все наші програмісти користуються одним і тим же набором візуальних компонентів, то, само собою, інтерфейс у програми буде виконаний в єдиному стилі. Більш того, помінявши, наприклад, вид одного з компонентів, ми змінимо його вид всюди, де він використовується.

Компоненти дають можливість незалежної розробки елементів інтерфейсу. Зміни всередині компонента не зачіпають код модулів, в яких він використовується. Розробка декількох незалежних класів дає приблизно ті ж результати, за винятком однієї проблеми. Серед програмістів середньої

кваліфікації спостерігається тенденція перемішувати функціональність класів, плутаючи методи одного класу з іншим. Компоненти поділяють код більш якісно.

Нарешті, накопичивши достатню кількість компонентів, можна дійсно швидко створити візуальний інтерфейс програми, фактично, не написавши більше жодного рядка коду!

Чим же доведеться заплатити за все це? Як це не дивно звучить, але платити доведеться об'єктно-орієнтованим підходом. Можливість гнучкого управління поведінкою компонентів за допомогою подій провокує написанням "подієво-орієнтованого" коду. Нехай, наприклад, нам потрібен компонент для відображення кольорових рядків. Об'єктно-орієнтований підхід зобов'язує нас створити спадкоємця класу ListBox і, перекривши метод Paint (), реалізувати отрисовку кольорових рядків. Можливість реалізувати подія OnPaint і не створювати ніяких класів підштовхує багатьох програмістів до використання подій на шкоду об'єктно-орієнтованого підходу. Саме "підштовхує", т. К. Ніхто не заважає створити новий компонент, що вміє малювати кольорові рядки на основі існуючого компонента ListBox. Такий підхід і буде найбільш вірним # 151; адже такі компоненти можна використовувати повторно!

Ще одна плата за зручність # 151; необхідність мати гнучкі компоненти. Немає сенсу писати компонент, який малює тільки рядки червоного кольору. Такий компонент буде важко використовувати будь-де, крім тієї програми, для якої він спочатку призначався. Набагато правильніше написати компонент, який малює рядки заданого кольору, а сам колір винести в його властивості (або якось зберігати всередині самої рядки). Ось такий компонент можна використовувати в будь-якій програмі. Така гнучкість вимагає деяких додаткових зусиль, необхідність затратити які не завжди очевидна при розробці однієї програми, але цілком окупається при повторному використанні компонента.

Підводячи підсумок цього міркування, можна сказати, що мета розробки нового компонента # 151; створення нової функціональності, що є неза? Мій, але гнучко настроюється частиною, що допускає повторне використання.

Візуальні іневізуальних компоненти в дизайнера форми

Бібліотека. NET Framework має два типи компонентів: візуальні і невізуал'ние. Візуальні компоненти є елементами призначеного для користувача інтерфейсу. Це, наприклад, компоненти: кнопка (Button), що випадає список (ComboBox) або мітка (Label). Невізуальні компоненти не мають призначеного для користувача інтерфейсу і не можуть розташовуватися на формі. Дизайнер Visual Studio розміщує їх внизу вікна дизайнера. Такими компонентами є, наприклад, компоненти роботи з базами даних, таймер (Timer), компонент роботи з послідовним портом (SerialPort) і ін.

Смороду дозволяти Вже у молодшому шкільному віці через комфортно побудоване навчання Сформувати здібності особистості до самовдосконалення саморозвитку самопізнання. Педагоги отрімають відповідь як сделать щоб Кожна дитина віріла в свои сили Викладаю на повну силу своих інтелектуальніх можливий та виросла впевнений в Собі ЛЮДИНОЮ поступово за годину навчання в школі віри в себе набувала вміння вчитись вірячі у Власні сили та впевнена набуваючі загальнолюдські уміння та навички. Реалізація проекту Школа Віри в себе.