Page 99 - 4190

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

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

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

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

або САПР. Може бути також каркас для створення компіляторів різ-
них мов програмування чи утворення додатків для фінансового моде-
лювання.

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

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

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

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

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

стосованих проектних рішень скорочується. У результаті додаток
створюється швидше. Крім того, усі додатки мають подібну структу-
ру. Їх простіше супроводжувати і користувачам вони виявляють

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

99