Студопедия

Главная страница Случайная страница

Разделы сайта

АвтомобилиАстрономияБиологияГеографияДом и садДругие языкиДругоеИнформатикаИсторияКультураЛитератураЛогикаМатематикаМедицинаМеталлургияМеханикаОбразованиеОхрана трудаПедагогикаПолитикаПравоПсихологияРелигияРиторикаСоциологияСпортСтроительствоТехнологияТуризмФизикаФилософияФинансыХимияЧерчениеЭкологияЭкономикаЭлектроника






Программа main отсутствует






 

Неоднократно подчеркивалось, что системы, разработанные с помощью ОО-подхода, не используют понятия основной программы. Не впускаем ли мы основную программу с черного хода, вводя определение корневого класса и корневой процедуры?

Не совсем. В традиционном понятии основной программы объединены две не связанные концепции:

[x]. Место, с которого начинается выполнение.

[x]. Вершина или фундаментальный компонент архитектуры системы.

Первое условие, безусловно, необходимо. Выполнение любой системы должно начинаться с вполне определенной позиции. В ОО-системах эта позиция определяется корневым классом и корневой процедурой. В случае параллельных, а не последовательных вычислений можно определить несколько начальных точек - по одной для каждой независимой нити или потока (Thread) вычислений.

Концепция вершины уже достаточно обсуждалась ранее и не требует дополнительных комментариев.

Нет никаких оснований для объединения столь разных понятий. Нельзя приписывать особую роль точке начала выполнения кода в архитектуре системы. Типичным примером может служить инициализация операционной системы, выполняемая процедурой загрузки. Этот небольшой и незначительный компонент безусловно нельзя считать центральным в архитектуре операционной системы. Объектная технология исходит из прямо противоположной предпосылки, считая, что важнейшими свойствами системы являются входящий в нее ансамбль классов, функциональные возможности этих классов и их взаимосвязь. В таком контексте выбор корневого класса играет второстепенную роль и при необходимости его можно легко изменить.

Ранее уже указывалось, что необходимо отказаться на раннем этапе разработки системы от вопроса, - " где основная программа? ". Если строить архитектуру системы на основе ответа на этот вопрос, то нельзя обеспечить расширяемость и повторное использование кода. Другой подход - готовые к повторному использованию классы, реализации АТД. Программные системы в этом случае представляют собой перестраиваемые ансамбли таких компонент.(О критике функциональной декомпозиции см. " Функциональная декомпозиция", лекция 5)

Не всегда конечной целью разработки является создание систем. Важным приложением метода является разработка библиотек классов для повторного использования. Библиотека это не система и она не имеет корневого класса. В процессе разработки библиотеки часто создают несколько систем, но такие системы используются только для отладки и не являются частью завершенной версии библиотеки. Окончательный продукт является набором классов, который другие разработчики будут использовать для разработки своих систем или своих библиотек.

 






© 2023 :: MyLektsii.ru :: Мои Лекции
Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав.
Копирование текстов разрешено только с указанием индексируемой ссылки на источник.