У меня есть некоторые Java-программы, теперь я хочу узнать, является ли она модульной или нет, если она модульная, то до какой степени, поскольку модульность никогда не может быть двоичным термином, то есть 0 или 1. Как я могу решить, код является модульным до такой степени. Я хочу знать, как сделать код более модульным?Как сделать код модульным?
Предполагая, что я понимаю ваш вопрос, что вы хотите знать, что это такое, что делает код модульным, поскольку для модулей кода, очевидно, потребуется какая-то зависимость между собой. Это мой ответ:
Если вы можете разбить систему на модули, и вы можете протестировать эти модули изолированно, что является хорошим показателем того, что система является модульной.
Как вы говорите, модульность не является бинарной вещью, поэтому она зависит от вашего относительного определения.
Я бы сказал: Можете ли вы использовать данный метод в любой программе, где вам нужно выполнить эту функцию? Это «черный ящик», где вам не нужно было знать, что он делает под капотом? Если ответ отрицательный, т. Е. Метод будет работать только в этой программе, тогда он не является действительно модульным.
Модульность относительно того, кто когда-либо разрабатывает код. Но я думаю, что общий консенсус в том, что модульный код - это код, который имеет части, которые можно легко обменивать без изменения большей части исходного кода.
IMHO Если у вас есть 3 модуля A B и C, и вы хотите полностью или полностью заменить модуль C, если это простая задача, то у вас есть модульный код.
Для анализа зависимостей между типами и пакетами можно использовать инструмент анализа кода, такой как CAP. Они помогут вам найти и удалить любые циклические зависимости, которые часто являются проблемой при разработке модульного кода. Если нет циклических зависимостей, вы можете начать разделять свой код на дискретные банки.
В целом, это хорошая практика для кодирования интерфейсов, если это возможно, это в целом означает, что ваш код легче реорганизовать и/или использовать в разных контекстах.
Конструкции для инъекций с зависимостями, такие как Spring, также могут помочь с модульной конструкцией вашего дизайна. Поскольку типы вводятся с помощью зависимостей посредством какого-либо внешнего процесса настройки, им не требуется прямая зависимость от реализации.
Некоторые контрольные показатели для модульности:
Для большего количества идей check this out и это один на software quality
Что касается вашей заботы о делает ваш код более модульным первым, вы должны задать себе эти вопросы, получить конкретные ответы на них, а затем посмотрит на this
Основная философия это сломать приложение в виде небольших фрагментов кода, как можно выстроены по множеству легко понятной и доступной макет каталога.
Каждый метод в вашей заявке должен выполнять не более минимальных квантов обработки, необходимых. Сочетание этих методов во всех более и более методы макроуровня должен привести вас обратно к приложению
Другим эталоном может быть «критерий удаления»: если вы удаляете X (пакет, класс, метод, поле) из своей программы, что происходит? Если есть перерывы, как «далеко» они от удаленного элемента? Если сломанные предметы отдалены, то это означает, что X не является модульным. –
(Добавить к предыдущему комментарию) - Когда вы что-то удаляете, вы сразу же показываете его соединения с остальной частью программы - все места, где она подключена к вызывающему коду. Более модульность * обычно * означает меньшее количество точек подключения и обычно означает, что точки подключения более «локальны» в области видимости (например, в одном пакете). –
+1! абсолютно правильно! – OrangeRind
Ключевых моментов
Хорошим примером такой модульной системы являются стандартные автомобильные детали, такие как дисковые тормоза и стереосистема. Вы не хотите создавать стереосистему с нуля, когда вы строите автомобили. Вы бы предпочли купить его и подключить. Вы также не хотите, чтобы тормозная система влияла на стереосистему автомобиля - или, что хуже, на стереосистему, влияющую на тормозную систему.
Чтобы ответить на ваш вопрос: «Как я могу решить, какой конкретный код является модульным до такой степени», мы можем задать вопросы для проверки модульности. Можете ли вы легко заменить свои модули чем-то другим, не затрагивая другие части вашего приложения?
Анализаторы XML могут быть еще одним примером. Как только вы получите интерфейс DOM, вам все равно, какая реализация парсера XML используется под ним (например, Apache Xerces или JAXP).
В Java еще один вопрос: Доступны ли все функции через interface? Интерфейс в значительной степени позаботится о низком сцеплении.
Кроме того, вы можете описать каждый модуль в своей системе одним предложением? Например, стереосистема воспроизводит музыку и радио. Тормоза диска тормозят автомобиль безопасно.
(Вот что я писал What is component driven development?)
Согласно Википедии, разработка на основе компонентов является псевдонимом для Component-based software engineering (CBSE).
[Это] является филиалом программного обеспечения техники, приоритет которого разделения интересов в отношении в широкой функциональности доступны всей данной системы программного обеспечения .
Это несколько расплывчато, поэтому давайте рассмотрим более подробную информацию.
Индивидуальный компонент представляет собой программный пакет , или модуль, который инкапсулирует набор связанных функций (или данные).
Все системные процессы помещаются в отдельных компонентов, так что все данные и функций внутри каждого компонента семантически связанных (так же, как с содержанием классов). Из-за этого принципа, часто говорят, что компоненты являются модульные и cohesive.
Таким образом, в соответствии с этим определением компонент может быть любым, если он делает одну вещь действительно хорошо и только одну вещь.
Что касается общесистемной координации, компоненты связываются друг с другом через интерфейсы . [...] Этот принцип приводит к компонентам, обозначенным как , заключенным в капсулу.
Так что это все больше напоминает то, что мы думаем о хорошем API или SOA.
условие интерфейсов представлены леденцом и требуется интерфейсы представлены символ открытого сокета, прикрепленный к внешнему краю компоненты в UML.
Другим важным атрибутом компонентов является то, что они замещаемой, так что компонент может быть заменен другим (в время разработки или во время выполнения), если требования к исходному компоненту (выраженные через интерфейсы) выполняются с помощью компонента-преемника .
Повторяемость является важной характеристикой высококачественного программного обеспечения . Компонент должен быть разработан и реализован так, чтобы его можно было повторно использовать во многих различных программах.
Подставляемость и повторное использование - вот что делает компонент компонентом. Так в чем же разница между этим и объектно-ориентированным программированием?
Идея в объектно-ориентированное программирование (ООП) является то, что программное обеспечение должны быть написаны в соответствии с ментальной модели реальных или воображаемых объектов, которые она представляет. [...]
основе компонентов программной инженерии, напротив, не дает никаких таких предположений, а вместо этого утверждает, что программное обеспечение должно быть разработано путем склеивания сборных компонентов вместе много как в области электроники или механика.
Чтобы ответить на конкретный вопрос как сделать код более модульным, несколько подходов:
Один из лучших инструментов для модульности является пятнистость код повторного использования. Если вы обнаружите, что ваш код делает то же самое (или очень похожее) вещь более чем в одном месте, это хороший кандидат для модуляции.
Определите, какие части логики могут быть сделаны независимыми, в том смысле, что другая логика будет использовать их без необходимости знать, как они построены. Это несколько похоже на то, что вы делаете в OO-дизайне, хотя модуль/компонент необязательно должен соответствовать моделируемому объекту, как в OO.
Идея package-by-feature помогает сделать код более модульным.
Много примеров видно на веб разделяй приложений первый в слои, а не особенности
кажется лучше, однако, чтобы разделить приложения используя пакеты верхнего уровня, которые выравниваются с функциями, а не слоями.
Веб-приложение example, использующее пакет по функциям. Обратите внимание на имена пакетов верхнего уровня, которые читаются как список фактических функций приложения. Также обратите внимание, как каждый пакет содержит все элементы, связанные с функцией - предметы не разбросаны по всему месту; В большинстве случаев все они находятся в одном каталоге/каталоге.
Обычно удаление функции в таком приложении может быть реализовано за одну операцию - удаление одного каталога.
Поскольку это было отмечено знаком «osgi», я могу использовать перспективу, связанную с OSGi.
Короткий ответ заключается в том, что можно перейти от полностью кодов спагетти к модульным небольшими шагами; это не должно быть большой взрыв. Например, даже код спагетти зависит от какой-то библиотеки регистрации болонских изображений, поэтому в некотором смысле она уже модульная, просто с одним очень большим металом (извините, модуль).
Трюк состоит в том, чтобы сломать большой фрикадель в один меньший кусок, а затем немного менее крупный фрикадель, а затем рекурсивно. Это не все должно быть сделано за один раз; просто чипайте немного больше каждый раз, пока ничего не осталось удалить.
Что касается OSGi, все равно можно положить uber-jar в связку. Фактически, вы можете сделать это без изменения бит; либо путем изменения Manifest.MF на месте, либо путем обертывания этого в другом JAR и указать Bundle-ClassPath: metaball.jar в манифесте.
В противном случае такие инструменты, как BND, могут помочь сгенерировать нужные вам данные, а затем его можно будет легко удалить в OSGi. Но будьте осторожны с чрезмерно связанным кодом и с тем, что галочки вокруг с загрузчиками классов - они вас отпустят.
Хей,
See, "Как герметизировать программное обеспечение (Часть 1)" здесь:
http://www.edmundkirwan.com/encap/overview/paper7.html
С уважением,
Ed.
Если код действительно модульный, каждый компонент должен быть черным ящиком. Чем меньше компонентов знаний знают друг о друге, тем более модульная система. – Kevin