Как сделать код модульным?

Некоторые тесты модульности:

1. Сколько раз вы переписывали аналогичный код для выполнения конкретная задача?
2. Сколько вам нужно рефакторинга кода при изменении некоторых часть вашей программы?
3. Являются ли файлы маленькими и легкими для навигации?
4. Адекватно ли и независимо работают ли модули приложения по мере необходимости?
5. Ваш код минимально опасен? Неужели все потеряно, когда вы удаляете только одну функцию или переменную? Получаете ли вы 20 с лишним ошибок при переименовании класса? (Чтобы проверить это, вы можете реализовать механизм стекирования, чтобы отслеживать все переходы в вашем приложении)
6. Насколько близок код к использованию естественного языка? (т.е. модули и их подкомпоненты представляют больше реальных объектов, не обращая особого внимания на чистый размер исходного файла).

Дополнительные идеи можно найти на странице это рекламное объявление о модульности и это о качестве программного обеспечения

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

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

Каждый метод в вашем приложении не должен выполнять больше необходимого минимума обработки. Объединение этих методов во все больше и больше методов макроуровня должно вернуть вас к вашему приложению.

Ключевые моменты

• Разделение проблем
• Сплоченность
• Инкапсуляция (общается через интерфейс)
• Заменяемость
• Возможность повторного использования

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

Чтобы ответить на ваш вопрос, как мне решить, что конкретный код является модульным до такой степени, мы можем сформировать вопросы для проверки модульности. Можете ли вы легко заменить свои модули чем-то другим, не затрагивая другие части вашего приложения?

Другим примером могут быть синтаксические анализаторы XML. Как только вы получите интерфейс DOM, вам действительно все равно, какая реализация XML-парсера используется под ним (например, Apache Xerces или JAXP).

В Java может возникнуть другой вопрос: Все ли функции доступны через interfaces? Интерфейс в значительной степени заботится о низком связывании.

Кроме того, можете ли вы описать каждый модуль в вашей системе одним предложением? Например, автомобильная стереосистема воспроизводит музыку и радио. Дисковые тормоза безопасно замедляют автомобиль.

(Вот что я написал в Что такое разработка, управляемая компонентами?)

Согласно Википедии, компонентная разработка - это псевдоним для Компонентной разработки программного обеспечения (CBSE).

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

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

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

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

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

Что касается общесистемной координации, компоненты взаимодействуют друг с другом через интерфейсы. [...] Этот принцип приводит к тому, что компоненты называются инкапсулированными.

Так что это все больше и больше похоже на то, как мы думаем о хорошем API или SOA.

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

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

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

Возможность замены и повторного использования - вот что делает компонент компонентом. Так в чем разница между этим и объектно-ориентированным программированием?

Идея объектно-ориентированного программирования (ООП) заключается в том, что программное обеспечение следует писать в соответствии с ментальной моделью реальных или воображаемых объектов, которые оно представляет. [...]

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

Чтобы ответить на ваш конкретный вопрос о как сделать код более модульным, можно предложить несколько подходов:

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

• Определите, какие части логики можно сделать независимыми, в том смысле, что другая логика будет их использовать, не зная, как они построены. Это несколько похоже на то, что вы делаете в объектно-ориентированном дизайне, хотя модуль / компонент не обязательно должен соответствовать моделируемому объекту, как в объектно-ориентированном дизайне.

Эй,

См. «Как инкапсулировать программное обеспечение (часть 1)» здесь:

http://www.edmundkirwan.com/encap/overview/paper7.html

С уважением,

Ed.

Поскольку это было помечено как «osgi», я могу добавить точку зрения, относящуюся к OSGi.

Короткий ответ заключается в том, что от полностью спагетти-кода к модульному можно перейти небольшими шагами; это не должно быть большим взрывом. Например, даже код спагетти зависит от какой-то библиотеки логирования болонского языка, так что в некотором смысле он уже модульный, только с одним очень большим метболом (извините, модулем) в нем.

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

Что касается OSGi, то убер-банку еще можно положить в бандл. Фактически, вы можете сделать это, не меняя биты; либо изменив Manifest.MF на месте, либо заключив его в другой JAR и указав Bundle-ClassPath: metaball.jar в манифесте.

В противном случае такие инструменты, как BND, могут помочь сгенерировать нужные вам данные, а затем их можно будет достаточно легко удалить в среде выполнения OSGi. Но будьте осторожны с чрезмерно связанным кодом и прочим, что мешает загрузчикам классов - они вас сбивают с толку.

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

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

Как вы говорите, модульность - это не двоичная вещь, поэтому она зависит от вашего относительного определения.

Я бы сказал: можете ли вы использовать данный метод в любой программе, где вам нужно выполнить эту функцию? Это «черный ящик», где вам не нужно знать, что он творит под капотом? Если ответ отрицательный, то есть метод будет правильно работать только в этой программе, тогда он не является истинно модульным.

Модульность зависит от того, кто когда-либо разрабатывает код. Но я думаю, что общее мнение таково, что модульный код - это код, в котором есть части, которые можно легко заменить без изменения большей части исходного кода.

IMHO, если у вас есть 3 модуля A B и C, и вы хотите полностью изменить или заменить модуль C, если это ПРОСТАЯ задача, то у вас есть модульный код.

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

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

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

Идея для каждой функции помогает сделать код более модульным.

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

• модели
• доступ к данным
• пользовательский интерфейс

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

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

Обычно удаление функции в таком приложении может быть реализовано за одну операцию - удаление одного каталога.