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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Обычно

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

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

Хей,

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

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

С уважением,

Ред.