Ключевые концепции - 3 Модульность в объектно-ориентированном программировании

Это окончание невероятной информации про .

...

некоторыми общественными организациями, можно назвать это принципом необходимого знания (need-to-know): запретить каждому модулю доступ к любой информации, которая не является безусловно необходимой для его надлежащего функционирования.

Ключевые концепции

• - Выбор надлежащей структуры модуля является ключом к достижению целей его возможного повторного использования и расширяемости.
• - Модули служат как для декомпозиции программного обеспечения (проектирование сверху вниз), так и для его композиции (снизу-вверх).
• - Принципы модульности применимы как к спецификации и проектированию, так и к реализации ПО.
• - Всеобъемлющее определение модульности должно объединять различные точки зрения; разные требования иногда оказываются взаимно противоречивыми, например декомпозиция (стимулирующая методы проектирования сверху-вниз) и композиция (способствующая использованию метода снизу-вверх).
• - Управление количеством и формой связей между модулями является основой разработки хорошей модульной архитектуры.
• - Для долгосрочной целостности структур модульной системы требуется скрытие информации, что приводит к необходимости строгого разделения интерфейса и реализации.
• - Унифицированный доступ освобождает клиентов от знания выбора внутренних представлений, реализованных в модулях-поставщиках.
• - Закрытым является такой модуль, который может использоваться, благодаря знанию его интерфейса, модулями-клиентами.
• - Открытым является такой модуль, который еще можно расширять.
• - Для эффективного руководства проектом следует поддерживать модули, являющиеся одновременно как открытыми, так и закрытыми. Но традиционные подходы к разработке и программированию не дают такой возможности.
• - Принцип Единственного Выбора предписывает ограничивать распространение полной информации обо всех вариантах некоторого понятия.

Библиографические замечания

В методе проектирования, известном как "структурное проектирование" [Yourdon 1979], особое значение придается важности использования модульных структур. Этот метод был основан на анализе "сцепления" и "связности" модулей. Но неявно выраженное представление модулей в структурном проектировании было основано на традиционном понятии подпрограммы, что ограничило рамки обсуждения. Принцип унифицированного доступа был первоначально предложен (под названием "унифицированная ссылка") в работе [Geschke 1975]. При обсуждении унифицированного доступа упоминался язык Algol W, преемник языка Algol 60 и предшественник языка Pascal (в котором были предложены некоторые интересные механизмы, не сохранившиеся в Pascal'е), разработанный Виртом и Хоаром, и описанный в работе [Hoare 1966].

Скрытие информации было предложено в двух основополагающих статьях Дэвида Парнаса [Parnas 1972] [Parnas 1972a].

Средства управления конфигурацией, которые будут перекомпилировать модули, затронутые изменениями в других модулях, исходя из подробного списка зависимостей между модулями, основаны на концепциях сервисной программы Make, первоначально разработанной для Unix [Feldman 1979]. Современные сервисные программы - а их имеется много на рынке программных средств - существенно дополнили функциональность основных идей.

В некоторых из приводимых ниже упражнений предлагается разработать метрики для количественной оценки различных неформальных критериев модульности, сформулированных в этой лекции. Некоторые результаты, относящиеся к ОО-метрикам, содержатся в работах Кристины Минджинс (Christine Mingins) [Mingins 1993] [Mingins 1995] и Брайана Хендерсон-Селлерса (Brian Henderson-Sellers) [Henderson-Sellers 1996a].

Упражнения

У3.1 Модульность в языках программирования

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

У3.2 Принцип Открыт-Закрыт (для программистов Lisp)

Многие реализации Lisp'а связывают конкретные функции с их именами не статически, а во время выполнения программы. Означает ли это, что язык Lisp лучше поддерживает принцип Открыт-Закрыт, чем статические языки?

У3.3 Ограничения на скрытие информации

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

У3.4 Метрики для модульности (отчетная исследовательская работа)

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

• - Модульная непрерывность.
• - Минимум интерфейсов.
• - Слабая связность интерфейсов.
• - Явные интерфейсы.
• - Скрытие информации.
• - Единственный выбор.

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

У3.5 Модульность существующих систем

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

Можете ли вы установить какие-нибудь взаимозависимости между результатами этого анализа (качественными, количественными, или теми и другими) и оценками структурной сложности исследуемой системы, основанными либо на ее неформальном анализе, либо, если это возможно, на реальных замерах затрат на ее отладку и сопровождение?

У3.6 Управление конфигурацией и наследование

Это упражнение предполагает знание механизма наследования, описанного далее в этом курсе. Его не стоит пока что выполнять, если вы дошли до этой лекции, изучая курс последовательно.

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

Если вы знакомы с конкретными средствами управления конфигурацией, выясните, как они взаимодействуют с механизмом наследования и другими принципами ОО-разработки ПО.

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

Продолжение:

Часть 1 3 Модульность в объектно-ориентированном программировании
Часть 2 Пять принципов - 3 Модульность в объектно-ориентированном программировании
Часть 3 Ключевые концепции - 3 Модульность в объектно-ориентированном программировании