Курсова робота на тему:«РЕАЛІЗАЦІЯ ОБ’ЄКТНО-ОРІЄНТОВАНОГО ПРОГРАМУВАННЯВ VISUAL BASIC .NET»

План

  1. Вступ.
  2. Складність управління проектами.
  3. Вимогу до гнучкості системи.
  4. Складність поведінки системи.
  5. У пошуках виходу з кризи.
  6. Декомпозиція в програмуванні.
  7. Об’єктно-орієнтоване мислення.
  8. Елементи об’єктного підходу.
    1. Абстрагування.
    2. Інкапсуляція.
    3. Модульність.
    4. Ієрархія.
  9. Роль мови в ООП
  10. Об’ектно-орієнтоване програмування Visual Basic.NET.
    1. Класи як абстрактні типи даних.
    2. Конструкція.
    3. Перевантаження методів класу.
    4. Змінні, що розділяються, в класах.
    5. Агрегація і спадкоємство.
    6. Поліморфізм.
    7. Абстрактні класи.
  11. Висновки.
  12. Список використаної літеретури.

    Вступ

Ви вже неодноразово зустрічалися з поняттями “об’єкт”, “метод”, “об’єктно-орієнтоване програмування” і тому подібне. Давайте детально ознайомимося з принципами об’єктно-орієнтованого програмування і постараємось зрозуміти, звідки вони виникли і чому набули такого широкого поширення. Для багатьох вас напевно буде несподіваним той факт, що ми живемо в епоху кризи програмного забезпечення. “Криза програмного забезпечення” не означає, що в світі комп’ютерів і додатків твориться щось недобре; просто все більш очевидною стає проблема: ми хочемо отримувати від комп’ютерів і комп’ютерних програм більше, ніж в змозі розробити. Іншими словами, наші потреби досить сильно розходяться з нашими можливостями.

Ще років двадцять тому мало хто міг припустити, наскільки широко використовуватимуться комп’ютерні системи в житті. Банківські перекази, найрізноманітніші системи управління (починаючи від організації бухгалтерії малого підприємства і закінчуючи системою управління залізницею цілої держави), відеомонтаж, збір і обробка даних з метеостанцій, розкиданих по всьому світу, — у всіх цих областях комп’ютери використовуються настільки інтенсивно, що вже важко собі уявити, як без них можна обійтися.

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

2.Складність управління проектами.

Вже давно помічено, що з лінійним зростанням обсягу тексту програми її складність зростає експоненціально. При цьому залучення додаткових сил, як правило, бажаного ефекту не дає: якщо п’ять програмістів пишуть програму за два місяці, то наївно вважати, що десять програмістів напишуть її за один місяць. Насправді, як показують деякі дослідження, у багатьох випадках результат залучення нових людей може бути прямо протилежним – інший раз краще доручити роботу двом-трьом програмістам, чим десяти. Передусім це пов’язано із задачею розподілу роботи між фахівцями. На жаль, розробка програмних систем – не зведення будинку; між програмістами набагато складніше розподілити обов’язки, чим між кранівниками, зварювальниками і штукатурами.

3.Вимогу до гнучкості системи.

У ідеалі процес розробки виглядає так: замовник проекту чітко (до дрібниць) викладає вимоги до проекту, в яких немає ні різночитань, ні туманних моментів. Програмісти реалізують систему, і після здачі проекту обидві сторони розлучаються, задоволені один одним. На практиці, на жаль, все відбувається зовсім інакше. Вже під час розробки виявляється, що замовник уявляє собі готовий проект не так, як програмісти. Створення системи — це завжди компроміс; замовник і розробники повинні постійно спілкуватися між собою і стежити за тим, щоб ухвалення будь-яких рішень влаштовували обидві сторони. Здачею проекту звичайна справа не закінчується: через деякий час існуюче вирішення замовника вже не задовольняє, і він звертається до розробників з пропозицією “допрацювати” або “частково переробити” проект.

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

Зрозуміло, в будь-якій системі є якісь фундаментальні елементи, внести зміни до яких дуже складно, але в той же час слід проектувати систему так, щоб скрізь, де можна, зміни вносилися без особливих ускладнень.

Складність поведінки системи.

Відмінність програмних систем від систем реального світу в тому, що вони є дискретними. Якщо ткнути автомобіль пальцем (навіть дуже сильно), він навряд чи вибухне або перетвориться на пил. Це відбувається тому, що об’єкти реального світу живуть по безперервних законах — невеликі дії спричиняють за собою невеликі наслідки. В світі комп’ютерних систем діють інші закони. Навіть сама незначна помилка в далеко не найважливішому модулі системи може спричинити непередбачувані наслідки (аж до повного краху системи). Боротися із цим неможливо; у наших силах тільки проводити уміле тестування (а при розробці сучасних систем тестування займає до 50 % загального часу роботи) і проектувати систему так, щоб локалізація і виправлення помилок відбувалися з найменшими затратами.

5. У пошуках виходу з кризи

Все-таки не можна не звернути уваги на те, що основна проблема не в складності програмних систем, як таких, а в нашій недосконалості. Дійсно, якби наш мозок був досконалою машиною, здатною утримувати сотні і тисячі деталей, найдрібніших подробиць системи, що розробляється, то проблема складності перестала б існувати сама собою! Та, на жаль, дослідження психологів говорять про те, що максимальна кількість одиниць інформації, за якими людський мозок здатний одночасно стежити, не перевищує семи-дев’яти. Оскільки радикальним чином змінити себе ми, швидше за все, не зможемо, доводиться шукати інші шляхи.

Насправді “золоте правило” (у своєму найзагальнішому формулюванні) відоме давно: розділяй і володарюй. Воно з успіхом застосовується в інших областях людської діяльності, пов’язаних з проектуванням. Ідея в тому, щоб розділити систему (провести її декомпозицію) на дрібніші (і прості) підсистеми. Після цього кожну з отриманих підсистем можна розробляти окремо.

Якщо подивитися на предмети, що оточують нас, то застосування принципу “розділяй і володарюй” стане очевидним. Наприклад, дисковод комп’ютера складається з магнітної головки, моторчика і електронної “начинки”. При цьому інженерам — творцям дисковода, ймовірно, не доводилося сушити голову над тим, як виготовити моторчик або яку-небудь мікросхему — їх завдання полягало в тому, щоб пристосувати готові мотори і мікросхеми для своїх потреб (або замовити їх виготовлення людям, які розуміють в електроніці, але, можливо, нічого не розуміють в комп’ютерах). Дисковод можна “ділити на складові” і дальше — аж до окремих гвинтиків і проводів (для їх створення знання комп’ютерних технологій вже точно необов’язково).

З цього прикладу можна зробити два важливі висновки.

1. Розробники на різних рівнях (система — підсистема) діють практично незалежно один від одного.

2. Розробникові системи більш високого рівня немає необхідності вникати в деталі систем нижчого рівня. Він повинен лише уявляти, що робить низькорівнева система, та не зобов’язаний знати, як вона це робить (конструктору дисковода байдуже, яким саме чином працює електродвигун; його цікавлять лише вхідні і вихідні характеристики).

6. Декомпозиція в програмуванні

Загальні фрази ніби “для ефективної роботи необхідно провести декомпозицію системи” ні у кого не викликають сумнівів. Проблема не в тому, щоб провести декомпозицію, а в тому, як її провести.

На жаль, до цих пір не відомий “кращий” спосіб розділення системи на підсистеми (і навряд чи такий існує в принципі). Можна говорити лише про різні підходи до цієї проблеми. Ось лише деякі з них:

  • структурне програмування;
  • сетод потоків даних;
  • автоматне програмування;
  • логічне програмування;
  • об’єктно-орієнтоване програмування.

Будь-який з цих підходів може виявитися найзручнішим для даного конкретного завдання; проте найбільшу популярність (цілком заслужену і перевірену часом) як підходи, придатні для вирішення завдань найширшого кола, отримали методи структурного і об’єктно-орієнтованого програмування.

Структурне програмування отримало широке поширення в 60-70-х роках (багато в чому завдяки роботам Э. Дейкстри). У його основі лежить ідея алгоритмічної декомпозиції: пропонується досліджувати складну систему на предмет різних алгоритмів, що застосовуються в ній, і реалізувати кожен алгоритм окремо. Саме структурне програмування заохочує процедурне мислення: якщо у вашій програмі деяка дія повторюється декілька разів, виділите цю дію в окрему процедуру. Ідеї структурного програмування відбиті в найпопулярніших мовах, створених в той період (наприклад, Algol 68, Pascal, С). Структурне програмування до цих пір залишається дуже хорошим (а нерідко і найкращим) підходом, якщо мова йде про невеликі проекти.

ЗАВАНТАЖИТИ

Для скачування файлів необхідно або Зареєструватись

Realizac OOP (291.5 KiB, Завантажень: 2)

Сторінка: 1 2 3 4 5 6 7 8
завантаження...
WordPress: 24.24MB | MySQL:26 | 0,347sec