Процес розробки компонентів в CBuilder

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

·&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp Визначте проблему, яку намагаєтеся вирішити

·&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp Знайдіть приватне рішення цієї проблеми

·&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp Зробіть рішення більш глобальним

·&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp Спроектуйте компонент для здійснення глобального рішення

·&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp Зробіть компонент якомога більш гнучким

·&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp Здійсніть ідею компонента в життя

·&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp Отладьте компонент

·&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp Протестуйте компонент

·&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp Створіть документацію по інтерфейсу компонента для кінцевого користувача (Тобто програміста, який буде використовувати цей компонент)

·&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp Проробіть роботу за поданням компонента (файли допомоги, іконки, визначення

палітр і т п)

·&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp Проінсталюйте компонент

·&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp Використовуючи накопичені знання, поверніться до першого кроку

Як ви бачите, розробка компонентів це безперервні пошуки рішення і формулювання проблеми Насправді шанси за те, що в день закінчення роботи над компонентом ви візьметеся переписати все заново, досить великі, так що в останньому пункті плану набагато менше гумору, ніж здається на перший погляд У своїй історичній книзі по розробці програмних продуктів «The Mythical Man-Month» Фред Брукс закликає писати першу версію програми з самого початку як чернетку, оскільки все одно доведеться переписувати Подібний підхід цілком підходить для розробки компонентів Прості на перший погляд кроки проектування, розробки та налагодження, а потім і використання компонента можуть завести вас дуже далеко в сторону в порівнянні з вашою початковою ідеєю Якщо ви вирішили, ледь закінчивши, переписати компонент заново (використовуючи, природно, багато чого з першої спроби, що істотно полегшить завдання), то, швидше за все, вдруге результат сподобається вам куди більше Компоненти і додатки, що не переписані після найпершої версії заново, зазвичай в результаті доробляються так жахливо, що навіть сам їх розробник не може впізнати своє дітище Вже повірте мені Я сам пробував стільки разів, що тепер навіть не думаю, що у мене що-небудь вийде з першого разу

Давайте розглянемо кожен крок процесу створення компонента трохи більш докладно Якщо ви настільки нетерплячі, що не хочете читати ці докладні вказівки з проектування компонентів, ви вільні пропустити цю частину голови і відразу звернутися до коду прикладів, але я не раджу вам так чинити Люди, які вважають, що знають про щось все, що треба знати, потрапляють зазвичай в одну з двох категорій: або вони, зрештою, усвідомлюють, що насправді не знають нічого, або стають безробітними Вчіться краще на чужих помилках

Важко порахувати, скільки разів я стикався з кодом, що містить помилки Помилки варіюються від абсолютно ідіотських (типу поділу на 0) до прямо-таки грандіозних, повязаних з тонкощами внутрішнього устрою операційної системи Windows (а іноді навіть і MS-DOS) І все ж більшість помилок виникає через те, що програміст не до кінця розуміє, чого ж він хоче добитися

Написання компонентів не тільки те саме написання будь-якого іншого коду, але і має додаткові особливості Якщо ви зробите помилку в описі методу одного із створених вами класів C + + в своєму додатку, виникнуть серйозні проблеми, але вони будуть обмежені додатком, в якому зявилися Якщо ви в якийсь момент виявили, що вам потрібно додаткові, або просто інші, параметри для методу, питання тільки в зміні опису методу і наступному зміну додатка Однак якщо ваш клас є частиною бібліотеки, то зясується, що зміна відібється на декількох додатках, що використовуються у вашій компанії Тепер, якщо звернутися компоненту, то стане ясно, що одне дрібне зміна може торкнутися сотні додатків, розроблених десятками компаній (якщо припустити, що ви комусь продали свій компонент) Через таких от маленьких виправлень ми й сходимо з розуму

Сідаючи за написання компонента, першою справою напишіть формулювання проблеми, яку хочете дозволити Формулювання може бути дуже простий, типу «Служить для виведення на екран зображень у форматі JPEG», або дуже складною, типу «Служить для здійснення взаємодії між багатьма компонентами на формі, для оповіщення кожного про зміну

іншого » Якщо ви не можете описати мета написання компонента в одній формулюванні, значить, ви не настільки добре уявляєте проблему, що б намагатися її вирішити На початковій стадії розробки формулювання проблеми буде, швидше за все, ставитися лише до додатка, з яким ви на даний момент працюєте Наприклад, вашій програмі може знадобитися блок, який би дозволяв користувачу по клацанню миші на тексті спеціального виду переноситися в інший текст на іншій формі Формулювання проблеми звучатиме як

«Створення компонента, що дозволяє переміщатися від однієї частини тексту підказок до іншого

за допомогою клацання миші »

Ви будете здивовані тим, яку допомогу може вам надати запис формулювання проблеми Вона постулює те, чим ви займаєтеся Якщо ваш шеф запитає вас, чим ви займалися останній тиждень, ви можете замість відповіді вручити йому формулювання проблеми Після того, як компонент написаний, і ви усвідомили його можливості, поверніться до формулювання проблеми і подивіться, чи дійсно він робить те, що повинен Формулювання проблеми часто допоможуть відмовитися від проблем власне програми Задавши формулювання проблеми, ви часто зможете знайти вже існуючий компонент, який би був в змозі впоратися з вашою проблемою без того, щоб ви писали щось самі Ось що може зробити одне невелике пропозицію, записане на клаптику паперу

Після того, як у вас зявилося формулювання проблеми, ви можете визначити шлях вирішення цієї проблеми На даній стадії розробки вам не треба думати про всі проблеми, з якими компонент допоможе впоратися, головне, щоб він вирішував поставлене завдання Якщо, наприклад, формулювання проблеми полягала у переміщенні між шматками файлів допомоги, рішення може бути визначено, як дозволяє користувачеві переміститися з точки A в точку B при натисканні на точку С

Найчастіше втілення в життя приватного вирішення проблеми – це все, що вам знадобиться Ви можете ніколи не перейти до наступного кроку (узагальнення), але ви, принаймні, розгляньте проблему і представите письмовий висновок по ній Після того, як ви знайшли приватне рішення проблеми, можете винести його на обговорення колег Може статися, ви дозволили проблему, а може бути, ваше рішення не працює, приймаючи в уваги всі обставини Наприклад, вашим рішенням могла стати перевірка слова під курсором і перескакування в інший файл довідки, що містить це слово Ваші колеги могли б вказати вам на те, що перескакування зі слова «тег» з документа з програмування сторінок HTML в документ про основи програмування – це навряд чи те, чого хотів би користувач Розробка приватного конкретного рішення може так само змусити вас повернутися на крок назад і переглянути формулювання проблеми

Отримавши приватна конкретне рішення конкретної проблеми, потратьте декілька хвилин, годин, днів, або чого там ще буде потрібно, і ще раз уважніше придивіться до проблеми Поглянувши на проблему більш узагальнено замість того, щоб концентруватися на окремих аспектах, ви можете виявити цілий клас подібних проблем, які можуть бути дозволені Деякі з найбільш яскравих і талановитих ідей в компютерному світі зросли з узагальнення рішень для приватних проблем

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

Фред Джонс зіткнувся з проблемою при написанні програми на CBuilder Йому потрібна

обмежити вводяться в деякі поля редагування значення тільки числовими Значення можуть бути будь-якої довжини, але вони повинні бути позитивними і можуть містити тільки цифри і десяткову крапку Ніяких шістнадцяткових уявлень, ніякого експоненціального виду і т д і т п Користувачеві дозволяється вводити лише десяткові цифри від 0 до 9 і десяткову крапку Фред відразу ж береться за роботу, наспіх повязуючи між собою рядки коду з якоїсь геніальної книги, яку він по щастю купив тільки напередодні (і яку ви зараз читаєте), і в результаті отримує-таки функцію у формі, яка як раз і робить те, що треба Фред задоволений, користувачі задоволені, програма працює відмінно, загалом, світ став трохи краще

Фреду належить робота з поліпшення програми і, до нещастя, він зясовує, що потрібні ще три форми з перевіркою вводятьсязначень подібного роду Фред розуміє, що одному тут не впорається Він з сумом віддається думкам про свою погубленої карєрі, а так само про те, що доведеться навчитися писати компоненти, щоб не погубити карєру остаточно Ретельно все обміркувавши, Фред вирішує докласти свої нові знання в області перевірки даних у числових полях, створивши компонент Компоненти, зрештою, річ досить непогана, а Фреду хочеться максимально скоротити кількість коду, яке припадає копіювати і вставляти в різні форми На думку Фреда, помилки, що виникають при копіюванні і вставці, складають до половини всіх помилок в програмі Так що якби він зміг уникнути копіювання, обєднавши код у вигляді компонента, він би позбувся половини помилок

Рішення створити новий компонент прийнято, і Фред старанно працює над цим Дуже скоро готовий компонент, який перевіряє, чи число введено в поле редагування, і відкидає всі, крім чисел Приблизно два тижні Фред ходить щасливий Після чого зясовується, що поля номера соціального страхування повинні дозволяти використання цифр і тире, поля дат – цифр і косих рисок, а поля спеціального реєстраційного номери – і цифр, і букв Фред пригнічений

Що само не правильно Фред вирішував приватну задачу з написання компонента для фільтрування даних для конкретного поля Але, на жаль, Фред не здійснив наступного кроку – узагальнення рішення Якби він розглянув проблему трохи більш широко, він би зрозумів, що набагато простіше було б дозволити користувачеві самому задавати фільтр для поля – безліч допустимих символів Ви можете здивуватися, чому Фред не використав компонент Masked Edit, що поставляється з CBuilder Справа в тому, що цей компонент не надає тієї гнучкості, яка потрібна Фреду Маска задається жорстко один раз, так що якби я захотів ввести 1234, або 1234, або 1245, я б не зміг написати маску, яка дозволила б це Компонент – поле редагування з фільтром, що сприймає значення 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, зможе зробити все, що треба Як тільки будуть зявлятися нові вимоги, Фреду треба буде змінити значення фільтра, щоб додати новий компонент на нову форму

Не можу не сказати і пару слів застереження: чи не заглиблюйтеся занадто глибоко в узагальнення Якщо ви спробуєте вирішити всі світові проблеми в одному компоненті, то зясуєте, що створеним вами компонентом ніхто не користується, оскільки він дозволяє вирішувати їх проблеми недостатньо просто Дозвольте спочатку невелику частину проблеми, а потім узагальнюйте рішення кожен раз так, щоб можна було використовувати цей елемент у більш великої завданню, і все у вас вийде

Тепер, коли ви знаєте, що саме вам треба зробити, настає найкритичніший момент у всьому процесі створення компонента – проектування компонента для дозволу поставленої проблеми Якщо ви правильно спроектували компонент і правильно намітили кроки для його

втілення, власне написання компонента стане досить простою річчю

Проектування – робота, якої дуже важко навчити У школах цьому не вчать – в них видають вже спроектовані речі і велять втілити їх У компаніях цього теж не навчитися

– Там зазвичай наймають професійного проектувальника, який розробляє зовнішні

специфікації програми Проектування це одна з тих речей, яким доводиться вчиться методом проб і помилок

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

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

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

Тепер, коли у вас в голові (або, що краще, на папері) є проект компонента, настав час для самого занятного – власне втілення компонента у вигляді коду CBuilder надає деяку допомогу для цього, але більшу частину роботи доведеться зробити все-таки вам Спочатку вам треба зробити скелет компонента, що містить всі властивості, методи і події, необхідні у відповідності з проектом

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

Розробка компонентів, втім як і будь-яких хороших програм – це процес циклічний Важко зробити все правильно з першої спроби, і неможливо добитися хорошого результату, не бажаючи змінювати проект, навіть при появі нових кращих ідей Справжнє мистецтво розробки компонентів насправді полягає в тому, щоб визначити той момент, коли треба зупинитися з втіленням нових ідей і відкласти перероблення системи до нової версії

Ми не будемо багато говорити про процес розробки компонентів, а замість цього сфокусуємо основну увагу на тих його частинах, які в іншому випадку вам довелося б переглядати під час розробки Велика частина глави присвячена розробці коду, а не розмовам

Після того, як розробка компонента закінчена, починається його налагодження У цій частині ми подивимося, як спочатку налагодити компонент, і як працювати з ним після інсталяції

Налагодження відноситься до області магії, причому, швидше за все, до чорної Якщо ви навчитеся деяким прийомам налагодження, ви можете далеко піти в світі створення програмних продуктів Зробіть відладчик CBuilder своїм іншому, а не ворогом, і ви виявите в ньому кілька дуже потужних інструментів

І останнє зауваження перед тим, як рухатися далі Налагодження – це не тестування Налагодити компонент – це означає зробити так, щоб він робив те, що він повинен робити за задумом Якщо я заявляю, що мій компонент малює лінію від одного свого кута до іншого, він саме це і повинен робити Налагодження – це перевірка, що він дійсно це робить Тестування ж це зовсім інше

Як я тільки що сказав, налагодження і тестування це різні речі Так що ж таке тестування Це перевірка не тільки того, що компонент робить диктував йому в обовязок речі, а й того, що він не робимо нічого такого, що робити в принципі не повинен Налагодження – це перевірка того, що правильно введені значення спричинять правильний результат, а тестування – це часто перевірка того, що неправильно введені значення так само призведуть до правильного результату (або правильній роботі)

Коли ви створюєте компонент, ви повинні дуже широко його протестувати Це означає набагато більше, ніж перевірка того, що введені значення викликають правильну реакцію Тобто якщо я постулює, що деяке поле повинно лежати в межах від 1 до 10, то введення 11, 0 або – 32768 не повинен викликати проблем І якщо одна властивість залежить від іншого, то компонент не повинен обрушитися, якщо друге поле не задано Це означає перевірку граничних умов для властивостей і методів

Граничні умови – це екстремальні обмеження на вводяться значення Якщо число має бути цілим і позитивним, то для нього граничними значеннями будуть 0, -1, 32767 і -32768 Вам також треба вибрати одне з лежать між ними допустимих значень, наприклад 1234, і перевірити, чи все працює як повинно Якщо у вас використовується небудь складний алгоритм, в якому виникають проблеми зі значеннями всередині допустимого діапазону, то тестування наведених вище пяти значень буде більш корисним, ніж просиджування по 12 годин за клавіатурою і тестування все підряд значень, які тільки прийдуть в голову

Для того, щоб бути дійсно дієвим, тестування має бути прогресуючим Тобто якщо я працюю над другою версією компонента, цей новий компонент повинен пройти всі

тести, що застосовувалися для його першої версії, також як і всі тести, які я придумав для перевірки нових можливостей версії два

Чесне попередження: більшість програмісти, як правило, тестують вельми плачевно Якщо ви дійсно хочете, щоб ваш компонент був добре протестований, нехай вам допоможуть інші люди (це називається бета-тестування)

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

Майте на увазі, що якщо ви не опишіть свій компонент, то їм ніхто не скористається У людей просто не буде часу на вивчення вихідного коду в пошуках підказки, як що-небудь зробити І на те, щоб розгадати допустимі значення для властивостей часу теж не буде Фірма Borland зробила використання компонентів в CBuilder настільки простим, наскільки це тільки було можливо без принесення в жертву гнучкості і мощі самих компонентів Так що тільки від вас залежить створення максимально дружелюбних до користувача компонентів

Не перевантажуйте користувача документацією Робіть вашу документацію простий і стислій, але в той же час зрозумілою Наприклад, якщо ви розробляєте компонент для роботи з датами, то можете запостуліровать, що всі зрозуміють, що являє властивість Month (місяць), чи не так А ось і ні У тому, чи лежать значення, що позначають місяці, в межах від 1 до 12 або ж від 0 до 11, є величезна різниця Ваша документація зобовязана донести цю інформацію до користувачів, тим більше, що це може виглядати дуже просто, наприклад:

Month: Номер місяця в даті значення цілі, від 0 до 11

Цей рядок повідомить мені все, що я хочу знати Що становить Day (день) взагалі не є таким вже очевидним Не зрозуміло – це день тижня або день місяця Присвоєння властивостями більш певних імен істотно полегшить життя Назвіть властивість DayOfMonth (день місяця), і ніхто вже не подумає, що це день тижня Правда, питання про те, відраховуються чи значення цієї властивості від 0 або від 1, все ще залишиться відкритим Будьте послідовні, і люди вас зрозуміють Кращим компліментом для творця компонентів може служити той факт, що програміст не дивиться в документацію тому, що всі компоненти працюють за одним принципом

Згадайте про те, як самі використовуєте компоненти, вбудовані в CBuilder Розібравшись в тому, як деяка властивість працює в одному компоненті, чи не вважаєте ви само собою зрозумілим, що і в інших компонентах воно буде працювати так само Ну звичайно ж, ви так вважаєте Ось чому так важливо допомогти користувачеві розібратися у всьому вперше – тобто надати йому хорошу документацію

У цій частині розробки вам треба висвітлити деякі аспекти, що стосуються вашого компонента: на якій сторінці палітри компонентів буде знаходитися ваш компонент, який іконкою він буде представлений, які файли допомоги будуть до нього ставитися і як він буде з ними повязаний

Хоча інсталяцією компонента займається середовище розробки (IDE), для вас теж є чим зайнятися Як ми побачимо в цьому розділі, в CBuilder є два варіанти тестування компонента В основному ви будете тестувати компонент в його первісному вигляді – до інсталяції (це займе набагато менше часу) У цій главі я покажу, як тестувати компонент до інсталяції Проте після завершення інсталяції вам доведеться протестувати компонент ще раз (регресивне тестування, памятаєте) Компоненти зовсім не завжди поводяться після інсталяції так само, як під час початкового тестування Вам треба обовязково упевнитися, що в обох випадках компонент працює коректно

Може здатися, що немає способів синсталліровать компонент, не маючи вихідного коду або обєктного файлу для нього Це не зовсім так Неправда і те, що можна синсталліровать в VCL CBuilder тільки один компонент за раз Якщо ви вийдете з IDE і створите бібліотечний файл (library file) для своїх компонентів, то зможете додати одразу кілька компонентів, або компонент, що складається з декількох файлів Правда, цей метод потребує додаткових зусиль Вам доведеться додати в свій компонент новий модуль з імям, що збігається з імям бібліотечного файлу, що містить функції Register для всіх компонентів бібліотеки Для того, щоб зрозуміти, як це має виглядати, зверніть увагу на бібліотеку compslib, що знаходиться в директорії доданого компакт-диска, що відноситься до даної глави Ви знайдете там модуль compscpp, що містить функцію Register для цієї бібліотеки, укладену в окрему іменовану область (namespace)

По-справжньому хороші компоненти ніколи не бувають дописані до кінця – в майбутньому ви будете оновлювати їх, підправляти, додавати в них нові можливості так що, закінчивши створення компонента, озирніться на виконану роботу і постарайтеся оцінити, що ж при цьому вивчили Часто-густо виявляється, що процес створення компонента відкрив вам очі на те, як треба проектувати і створювати компонент на насправді Памятайте, – розробити один пробний «на викид» – все одно так і вийде

Отже, тепер ви знаєте все, що треба, про розробку компонентів, чи не так Може бути Давайте спробуємо свої сили і прямо зараз створимо кілька справжніх компонентів Ми почнемо з простого і будемо поступово ускладнювати завдання, як звичайно

Джерело: Теллес М – Borland C + + Builder Бібліотека програміста – 1998

Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*