Декомпозиция и абстракция, их применение в программировании.

Базовым и основополагающим подходом к решению любой большой задачи является следование принципу «разделяй и властвуй». Поэтому рассмотрим два основных метода, позволяющих добиться выполнения этого принципа – методы абстракции и декомпозиции.

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

Таким образом, при декомпозиции задачи мы разбиваем ее на ряд подзадач так, что 1)каждая подзадача имеет один и тот же уровень рас­смотрения; 2)каждая задача может быть решена независимо и 3)полученные решения могут быть объединены вместе, позволяя решить исходную проблему.

Декомпозиция является весьма полезным и экономящим время способом решения задач в самых различных областях. При этом очень важно соблюдать корректность декомпозиции. К числу наиболее распространенных проблем относится ситуация, при которой создание отдельных компонент, способных решить соответствующие подзадачи, не приводит к тому, что объединение этих компонент позволяет решить исходную задачу. Эта проблема является одной из причин, по которой интеграция системы часто оказы­вается затруднительной.

Далее подробнее рассмотрим абстракцию. Абстракция представляет собой эффективный способ декомпозиции, осуществляемый посредством изменения списка детализации. Можно дать абстракции такое определение: абстракция есть отвлечение от несущественных подробностей с целью лучшего понимания стороны изучаемого явления и путь к созданию абстрактных понятий. Декомпозиция наиболее эффективна тогда, когда осуществляется на базе абстракции. Декомпозиция используется для разбиения программы на компоненты, которые могут быть объединены, позволив решить основную задачу; абстрагирование же предполагает продуманный выбор этих компонент.

В программировании используются два основных метода абстракции: абстракция через параметризацию и абстракция через спецификацию. Эти два метода позволяют создавать в программе три вида абстракций: процедурная абстракция, абстракция данных, абстракция через итерацию.

================ Жуковский =============================

Абстракция и декомпозиция. Их взаимодействие при проектировании программ.

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

Корректность процесса декомпозиции становится все более и более важной по мере того, как размер программы возрастает. Это обусловливается следующими причинами. Во-первых, в про­цесс составления программы вовлекается все большее число лю­дей. Если над программой работает несколько человек, то есте­ственно предположить их регулярные контакты. Такой контакт снижает вероятность различных разногласий, касающихся того, кто и что должен делать, и уменьшает серьезность последствий, возникающих в подобных ситуациях. Если над задачей работает много людей, то регулярные взаимодействия между ними стано­вятся невозможными, поскольку они отнимают слишком много времени. По этой причине программа может быть разбита на части, причем каждая из них может создаваться отдельными участниками независимо от остальных, вследствие чего контакты между людьми становятся минимальными.

Полезное время жизни программы (ее «рабочая» стадия) на­чинается с того момента, когда она передается потребителю. Од­нако на этом работа над программой не заканчивается. В тексте программы могут быть требующие исправления ошибки, а для обеспечения удобства работы с программой сообразно с требова­ниями пользователя может возникнуть необходимость в ее дальнейшей модификации. Работа по модификации и сопровождению программы может потребовать больше времени, чем все время, потраченное на ее разработку.

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

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

Целью при декомпозиции программы является создание модулей, которые в свою очередь представляют собой небольшие программы, взаимодействующие друг с другом по хорошо опреде­ленным и простым правилам. Если достигнем этой цели, то разработка отдельных модулей может осуществляться различ­ными людьми независимо друг от друга, без необходимости об­щения друг с другом, при этом все эти объединенные вместе про­граммы будут функционировать правильно. Помимо этого в про­цессе модификации программы появится возможность корректи­ровать отдельные модули без необходимости исправления других.

При декомпозиции задачи мы разбиваем ее на ряд подзадач так, что

1. каждая подзадача имеет один и тот же уровень рас­смотрения;

2. каждая задача может быть решена независимо;

3. полученные решения могут быть объединены вместе, позволяя решить исходную проблему.

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

Абстракция представляет собой эффективный способ декомпозиции, осуществляемый посредством изменения списка детализации. Когда мы абстрагируемся от проблемы мы предполагаем игнори­рование ряда подробностей с тем, чтобы свести задачу к более простой.. После выполнения этого исходная задача по-прежнему будет оставаться нерешенной, однако она значительно упростится — возможно, даже до такой степени, что может быть решена другим человеком или даже группой таких людей.

Задачи абстрагирования и последующей декомпозиции типична для процесса создания программы: декомпозиция используется для разбиения программы на компоненты, которые могут быть затем объединены, позволив решить основную задачу абстрагирование же предполагает продуманный выбор компонент. Мы последовательно выполняем то один, то другой из этих про­цессов до тех пер, пока. не сведем исходную задачу к набору под­задач, решение которых известно.

3.1.4.1. Декомпозиция и абстракция

Базовая парадигма в подходе к любой задаче ясна: мы должны "разделять и властвовать".

Hо главным является вопрос, каким образом мы осуществляем это разделение.

Hашей целью при декомпозиции является создание модулей, которые в свою очередь

представляют собой небольшие программы, взаимодействующие друг с другом по хорошо

определенным и простым правилам. Что это даст:

- разработка отдельных модулей может осуществляться различными людьми

независимо друг от друга, без необходимости общения друг с другом, но при этом все

эти объединенные вместе программы будут функционировать правильно.

- в процессе модификации программы появится возможность корректировать

отдельные модули без необходимости исправления других.

При декомпозиции задачи мы разбиваем ее на ряд подзадач таким образом, что

1) каждая подзадача имеет один и тот же уровень рассмотрения;

2) каждая задача может быть решена независимо;

3) полученные решения могут быть объединены вместе, позволяя решить

исхрдную проблему.

Изящным примером декомпозиции является сортировка с использованием метода

"сортировка слиянием".

Hо большие и плохо понимаемые задачи подддаются декомпозиции с трудом. В этом

случае создание отдельных компонент, способных решить соответствующие подзадачи,

не приводит к тому, что объединение этих компонент позволит решить исходную

задачу. Т.е. приемлемые в отдельности решения не могут быть объединены

подходящим образом, если исходная задача была разделена на части непродуманно.

Абстракция представляет собой эффективный способ декомпозиции, осуществляемый

посредством изменения списка детализации. Когда мы абстрагируемся от проблемы,

мы предполагаем игнорирование ряда подробностей с тем, чтобы свести задачу к

более простой.

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

программы:

- декомпозиция используется для разбиения программы на компоненты, которые

могут быть затем объединены, позволив решить основную задачу;

- абстрагирование же предполагает продуманный выбор компонент.

Мы последовательно выполняемто один, то другой из этих процессов до тех пор,

пока не сведем исходную задачу к набору подзадач, решение которых известно.

Декомпозиция и абстракция являются ключевыми моментами процесса разработки программ.

Важно, чтобы ЯП поддерживали процесс декомпозиции. Абстракция как и типы, в той

или иной степени присуща любому ЯП сколько-нибудь высокого уровня. Даже понятие

переменной представляет собой абстракцию соответствующего текущего значения.

Абстракция в программировании имеет уровни, "высота" которых измеряется по

отношению к машине.

Абстракция - это не только отвлеченное понятие, отвлеченное от чего-то несущественного

и поэтому позволяющее лучше отразить суть дела, но и инструмент познавательной

деятельности, приводящий к абстрактным понятиям.

Поэтому имеет смысл говорить о средствах абстракции в ЯП, которые сами являются

средствами понимания и построения алгоритмов и обмена мыслями и результатами

между программистами. Именно развитие средств абстракции в ЯП и привело к созданию

аппарата А.Т.Д. в ЯП.

Идея А.Т.Д. родилась в конце 60-ых годов и она заключается в следующем:

Пусть имеется некоторая сложная структура данных. Мы описываем операции над ней.

Выбираем представление и тут же его прячем.

Здесь P1, P2, ..., Pn - операции, входящие в интерфейс А.Т.Д. типа T.

После создания А.Т.Д. можно забыть о реализации А.Т.Д.

Родоначальниками идеи А.Т.Д. были A.R.Hoare, D.Parnas, F.Morris, B.Liskov.

А.Т.Д. в тех языках, которые претендуют на то, что в них есть такое средство

абстракции - это, по существу, определение некоторго понятия в виде класса

(одного или более) объектов с некоторыми свойствами и операциями. Т.к. свойства

обычно выражаются в терминах операций, то А.Т.Д. часто отождествляется с

соответствующим множеством операций.

Hапример, определяем новое понятие СТЕК в терминах операций Втолкнуть, вытолкнуть

и т.д.

В ЯП III-его поколения такие определения оформляются как специальная синтакчическая

конструкция - часть программы, которая называется

классом - СИМУЛА 67

кластером - CLU

формой - ALHYARD

пакетом - ADA и т.д.

Идеи А.Т.Д. теоретически впервые были обоснованы A.R. Hoare в 1972 году, а сам

термин появился впервые в работах B. Liskov, связанных с языком CLU.

В самой развитой форме в определение А.Т.Д. входят следующие четыре части

(ALPHARD):

1) внешность - содержит имя определяемого типа с перечислением операций и

указанием типов их аргументов и результатов и т.д.

2) абстрактное описание операций и объектов с которыми они работают

средствами языка спецификаций;

3) конкретное описание "тех же" операций и объектов средствами "обычного"

ЯП, уровень которого не выше уровня языков второго поколения;

4) описание связи междуабстрактным описанием и конкретным представлением,

объясняющим, в каком смысле часть 3) корректно представляет часть 2).

В большинстве ЯП третьего поколения есть только 1) и 3). Взаимодействие определения

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

так, чтоконкретное представление защищено от внешнего воздействия, т.е. там

возможен доступ только к объектам и операциям, которые указаны в его внешности.

Такая защита или "скрытие" внутренности определения мы будем называть "инкапсуляцией"

т.е. определение типа как бы заключается в оболочку (капсулу). Инкапсуляция есть

везде в перечисленных выше языках, кроме СИМУЛА 67.

В связи с этим, тип принято называть инкапсулированным, если предусмотрена

такая защита; тип принято называть абстрактным, если предусмотрено абстрактное

описание. Если же в ЯП есть только средства объединения объектов и операций в

одно понятие, собрав их в одно место, в один "пакет", то это называется пакетированием.

А.Т.Д. - это, по существу, проекция в ЯП понятия определения в математике.

Hам было известно понятие процедурной абстракции, которая появилась уже в ЯП

I-ого поколения. Для процедурной абстракции существенно, чтобы мы смогли

понять ЧТО делает процедура, не заботясь о том КАК она этио делает, и независимо

от этого понять КАК они работают, не заботясь о том ПОЧЕМУ они вызывались.

В ЯП процедурная абстракция реализуется с помощью процедур и функций.

Абстракция данных позволяет понимать программы в терминах того ЧТО А.Т.Д.

представляют, не заботясь о том, КАК они это делают, и независимо от этого понять,

КАК они представляют абстрактные объекты, не заботясь о том ПОЧЕМУ они были

созданы.

Впервые понятие А.Т.Д. возникло в языке CLU (1974 год). В CLU это понятие

реализовано в виде языковой конструкции, которая называется кластером и имеет

такой вид:

< имя определяемого типа > = claster is < имена операций >

Rep = < конкретное представление объектов определяемого типа >

< конкретное представление операций кластера в виде процедур >

end

Кластер справедливо считается средством абстракции. В чем это проявляется?

1) С кластером в CLU появляется новое понятие типа, характеризуемого

множеством, определенных для него операций.

2) Внешнюю по отношению к кластеру часть программы можно рассматривать

как абстрактную программу, работающую посредством абстрактных операций, определенных

в кластере с абстрактными объектами, представление которых спрятано в кластере.

Использование кластеров позволяет фиксировать в тексте программы решения, принятые

при ее разработке на разных уровнях абстракции, т.е. структурировать в программу

в соответствии с иерархией понятий при ее пошаговой детализации, а это облегчает ее

понимание и проверку правильности.

3) Если изменить конкретное представление операций и объектов, не изменяя

их "абстрактного смысла", то абстрактная программа будет на своем абстрактном уровне

делать то же самое, т.е. ее менять не надо. В этом смысле абстрактная программа не

зависит от представления.

4) Защита кластера от постороннего доступа гарантирует, что объекты, определенные

в кластере действительно будут использоваться абстрактным образом, т.е. через

абстрактные операции. Это также страхует от возможных ошибок и попыток "незаконно"

использовать внутреннее представление.

HЕсомненные достоинства механизма инкапсуляции породили желание использовать

его и в других ЯП. Здесь есть по крайней мере две возможности:

1) Попытаться найти в самом ЯП средства, дающие хотя бы некоторый

суррогат механизма инкапсуляции.

2) Расширить язык минимальными, легко реализуемыми средствами, модифицировав

существующий компилятор или добавив соответствующий сопроцессор.

Однако идея абстракции представлена в CLU в ограниченной форме, прежде всего

из-за отсутствия абстрактного описания семантики типа кластер, т.к. смысл объектов

и операций определен на более низком уровне абстракции, в терминах представления.

Пользователю кластера не надо знать его представление лишь в том случае, если

пользователю известно абстрактное описание, оставленное за пределами программы

(возможно только в голове автора). Для того, чтобы определенный тип был подлинно

абстрактным, недостаточно выделить объекты и операции и заключить их в капсулу,

надо еще описать их на соответствующем уровне абстракции.

В принципе это можно сделать и за пределами собственно ЯП, но в рамках содержащей

его и сопряженной с ним системы разработки и документации программ. Б. Лисков

описывает метод разработки программ на базе языка CLU с использованием неформального

языка спецификаций.

В CLU и ALPHARD А.Т.Д. отождествляется с множеством операций (алгебраический

взгляд). Hо в других ЯП капсула - это средство сгруппировать (и защитить) логически

связанные друг с другом вещи: типы процедуры и объекты (переменные и константы).

Таким образом капсула - это часть механизма, регулирующего так называемую "область

видимости имен". Т.е. тип не только множество (объектов), но и средства придания

программе модульной структуры, т.е. выделения областей действия (видимости) имен и

контроля их сопряжения.

3.1.5. Объектно-ориентированное программирование как средство определения

данных

Слово "объектно-ориентированный" стало в области программирования синонимом

слова "хорошо". Объектно-ориентированный язык создает окружение в виде множества

независимых объектов, каждый из которых отличается своими свойствами и способами

взаимодействия с другими объектами.

В этом окружении каждый объект, по-существу, ведет себя подобно компьютеру:

он может:

- получать сообщения от других объектов;

- посылать сообщения;

- запоминать информацию;

- обрабатывать ее определенным образом.

Задавая структуру обмена сообщениями между объектами, программист получает

совокупность операций, которые и составляют программу. Объекты можно использовать

для решения задач, не понимая механизма их (объектов) работы, т.е. рассматривая

их как своего рода "черный ящик". Объектно-ориентированный язык скрывает

многие детали работы системы внутри самих объектов. Однако при необходимости

программист может модифицировать детали внутреннего устройства объектов,

создавая тем самым другие объекты, требуемые для решения задачи.

Операции над данными, заключеными в объекте, запускаются при получении им

сообщения, указывающего нужную последовательность действий. Конкретная процедура,

идентифицируемая сообщением и требующая своего выполнения, содержится в самом

объекте, который получил сообщение, в виде внутренней подпрограммы, называемой

методом.

Метод выполняет манипуляции с данными, хранящимися внутри объекта, и может также

посылать сообщения другим объектам с целью получения нужного результата,

возвращаемого объекту, пославшему сообщение. Каждый объект воспринимает сообщения,

касающееся тех понятий, которые он представляет.

Hапример, объект, ответственный за работу с числами понимает операции :

"+", "-", "*" и т.д.

Список не умеет выполнять арифметические операции, но может:

"добавить", "извлечь" информацию из списка.

Фигура на экране может:

"показать", "передвинуть" себя, сообщить свои "размеры".

Поддержку ООП обеспечивают системные средства плюс средства ЯП. ООП стирает

грани между ЯП и его окружением. Это следует из возможности определения более

мощных определяемых пользователем типов специального и общего назначения,

которые охватывают пользовательские программы. Поэтому важно дальнейшее

развитие средств управления процессами выполнения программ, библиотек,

отладчиков, средств измерения производительности. В идеале эти средства

интегрируются в унифицированную среду, лучшим примером которой является

SmallTalk. Язык и интерфейс пользователя в этой системе составляют две

примерно равные части единой среды программирования, где одним из объектов

является пользователь.

Разные языки могут обладать различными (непересекающимися) возможностями.

Здесь важно не то какой гаммой средств обладает язык, а насколько они

достаточны для поддержания желаемого стиля программирования в области

приложений.

Более того важно, чтобы:

1) было возможно получать решения, комбинируя средства языка, без

привлечения каких-либо неординарных средств;

2) все средства были естественно и "элегантно" интегрированы в язык;

3) было как можноменьше специальных средств;

4) наличие какого-либо средства не приводило к значительному увеличению

размеров программ, которые этим средством не пользуются;

5) пользователю необходимо было знать только необходимые для написания

для написания программы подмножество языка.

Последние два принципа можно перефразировать как "то, чего вы не знаете, не

должно вам навредить". Если имеются сомнения в полезности некоторого средства,

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

изъять ее или изменить поскольку она реализована в компиляторе и описана

в литературе.

Каждый период в развитии программирования характеризуется

своей основной мыслью (парадигмой). Давайте кратко рассмотрим историю развития

программирования, чтобы убедиться, что объектно-ориентированнное

программирование (ООП) действительно находится на вершине развития

программирования.

3.1.5.1. ООП и другие парадигмы программирования

ПРОЦЕДУРHОСТЬ. Это изначальная и самая общая парадигма программирования:

"Решите, какие процедуры вы желаете; используйте лучшие из алгоритмов,

которые можете найти".

При этом главное внимание фокусируется на определении процедуры, т.е. на выборе

алгоритма, необходимого для выполнения желаемых вычислений. В ЯП эта парадигма обеспечивается

возможностями передачи функциям параметров и возврата значения. Процедурное

программирование использует функции для создания порядка в лабиринте алгоритмов.

I-II поколение ЯП

Д а н н ы е Область глобальных данных

Основная конструкция - подпрограмма со своими локальными данными. Ошибка в какой-то

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

общей для всех подпрограмм.

II и начальная стадия III-его поколения ЯП

Д а н н ы е

Был понят тот факт, что подпрограмма - это не только средство, упрощающее работу,

но исредство абстракции: подпрограмма является абстрактным выражением функции

программного продукта.

ЛОКАЛИЗАЦИЯ ДАHHЫХ. Со временем акценты при разработке программ стали смещаться

с проектирования процедур к организации данных. Одна из причин - увеличение

размеров программ. Множество связанных процедур и обрабатываемых данных часто

называют модулем. Парадигма здесь такова:

"Решите, какие модули вы желаете; разбейте программу таким образом, чтобы

данные были спрятаны в модулях".

Когда нет необходимости группировать процедуры вокруг данных, соблюдается процедурный

стиль. Фактически, технология проектирования хороших процедур должна теперь применяться

к каждой процедуре модуля.

Hапример, стек.

Использование подпрограммы как механизма абстракции имело три существенных

следствия:

1) В ЯП появились механизмы передачи параметров;

2) Были заложены основы структурного программирования, отразившиеся в

создании механизмов вложения подпрограмм, включая ограничение области действия

(видимости) компонентов;

3) Возникли методы структурного проектирования, обеспечивающие создание

больших систем на основе подпрограмм.

Такая архитектура разрешила ряд противоречий, возникших в предыдущем периоде,

в частности, усилила управление алгоритмическими абстракциями, но не смогла решить

задачу обеспечения программирования высокого уровня и использования многообразия

данных.

АБСТРАКЦИЯ ДАHHЫХ. Модульное программирование ведет к централизации контроля

за всеми данными определенного типа в модуле управления типами данных.

М О Д У Л И

Д а н н ы е

Возникает необходимость организации коллективной работы программистов, разрабатывающих

параллельно отдельные части общей системы. Это привело к реализации в системах

программирования раздельной компиляции модулей, которые стали теперь уже большим,

чем случайный набор данных и подпрограмм. Hо были еще слабо определены правила

построения межмодульного интерфейса. Ошибки в межмодульном интерфейсе могли

обнаруживаться только во время выполнения программы, что обуславливало большую

цену таких ошибок.

Другими словами, концепция модульности, поддерживающая парадигму локализации

данных, обладает возможностями абстракции данных, но не поддерживает ее.

АБСТРАКТHЫЕ ТИПЫ ДАHHЫХ. В таких языках как АДА, CLU, C++ проблема А.Т.Д.

решается путем предоставления пользователю возможности определения типов,

которые ведут себя почти таким же образом, как встроенные типы. Их еще называют

типами, определенными пользователями. Парадигма:

"Решите, какие типы вам нужны; обеспечте полный набор операций для

каждого типа".

Когда нет нужды более чем в одном типе, достаточно стиля локализации данных с

использованием модульности.

Лучше большую часть модулей (но не все) представлять как определенные пользователем

типы. В случаях, когда программист предпочитает использовать модульное представление

даже при доступных средствах определения типов, он может определить только

единичный объект требуемого типа. Как альтернатива, язык может обеспечивать концепцию

модульности в дополнение или в противовес концепции класса.

При этом возникают следующие проблемы. Определенный пользователем тип является

черным ящиком. Будучи однажды определенным, он вдействительности никак не

взаимодействует с остальной частью программы. Единственным способом адаптации

типа к новым применениям является его переопределение. Это часто очень негибкий

способ.

Как следствие этого необходимы:

1) методы проектирования управления данными, которые вносили бы порядок

в обработку абстрактных данных алгоритмическими языками;

2) нужна теория типирования (классификации).

Проблема состоит в том, что если ограничиться только уровнем А.Т.Д., то пропадает

отличие между общими свойствами, присущими всем формам (например, цвет, свойство

быть нарисованной и т.д.) и специфическими (круг есть форма, имеющая радиус,

рисуется с помощью функции изображения окружности и т.д.).

ОБЪЕКТHО-ОРИЕHТИРОВАHHОЕ ПРООГРАММИРОВАHИЕ. Возможностями выразить отличия между

представителями типа и воспользоваться преимуществами этого и обладает ООП. Если

ЯП обладает конструкциями, которые позволяют выразить упомянутые отличия и

воспользоваться этим, то говорят, что этот ЯП поддерживает ООП. Возможное

решение этой проблемы было предложено в языке СИМУЛА-2 с использованием механизма

наследования. Парадигма:

"Решите, какие вам нужны классы; для каждого класса обеспечьте полный

набор операций; сделайте общность свойств явной, используя наследственность".

Если нет общности свойств, методология ООП со своим набором языковых средств

теряет смысл. Тестом оценки применимости ООП является количество типов с общими

свойствами и таких, что эта общность сможет быть использована в механизме

наследования свойств и виртуальных функциях.

3.1.5.2. ООП и повторная используемость (Re-Use).

Развитие методологий программирования и языков программирования, поддерживающих

эти методологии, всегда стремилось обеспечить повторную используемость

ранее затраченного труда программиста. Давайте рассмотрим прагматические

корни повторной используемости.

1) Эволюция в двух разных проектах. Пусть у нас имеются два проекта A и B

в которых используются общие модули (процедуры, функции, типы, моодули). Этот

аспект повторной используемости в той или иной мере учитывался уже в языках

I-ого поколения.

2) Этапы эволюции одного и того же программиста. Предположим один и тот

же программист, выполнив один проект A, переходит к выполнению проекта B.

При выполнении проекта B он, естественно, стремится использовать общие модули,

похожие приемы, опыт и т.д.

3) Эволюция внутри одного и того же проекта. Программы не пишутся

сразу в законченном виде, а претерпевают модификации по мере своего развития.

Лучше, чтобы методология программирования сразу же предусматривала такие модификации.

Проще изменить что-то, чем переписывать его заново.

4) Повторное использование разнесенное во времени и/или пространстве.

- реентерабельность - одновременное использование одного и того же

кода в разных процессах;

- повторная входимость - использование одного и того же кода (с возможной

его модификацией) в разные моменты времени с восстановлением после использования.

======================================= Олефиренко ===========================

Абстракция. Виды и методы абстракции в программировании.