TL; DR не один волшебного решения пули, но много различных инструментов, использовать
Есть множество различных методов, чтобы изолировать различные части программного приложения, но я не думаю, что есть какое-то одно решение, которое решает все. Некоторые системы сборки могут ограничивать зависимости между целевыми объектами (например, Bazel имеет свойство visibility для целей построения, которое может помешать одной цели в зависимости от другой цели, даже если они видны друг другу через видимость класса Java), которые могут использоваться в сочетании с Java встроенный видимость. Например:
// Foo.java
package com.yourcompany.foo;
public class Foo {}
// Build rule for Foo.java
java_library(
name = "Foo",
srcs = ["Foo.java"],
# Restricts visibility to this directory, even though
# the class visibility was "public"
visibility = ["//visibility:private"],
)
// Bar.java
package com.yourcompany.bar;
import com.yourcompany.foo.Bar; // prevented by build visibility system
public class Bar {
Foo foo = new Foo();
}
Кроме того, можно использовать интерфейсы, чтобы опосредовать все взаимодействия между логическими компонентами и, чтобы скрыть реализации этих интерфейсов (например, подвергая реализации только через интерфейс реестра службы или через инъекцию зависимостей интерфейса). Например, с Dagger, вы можете создать отдельный component для каждого слоя, который позволит вам написать код:
final class ControllerImpl implements Controller {
// Since "ControllerImpl" is instantiated/wired into the
// controller layer, the database dependency is available/
// exposed for injection within this layer. The access control is
// strictly performed by the way the dependencies are wired.
@Inject
public ControllerImpl(Database database) {
// ...
}
}
В дополнение к вышесказанному, можно использовать тесты для анализа анализа зависимостей/зависимостей или фиксации крючков автоматизировать обнаружение нарушений правил зависимостей (и инициировать ошибки/отклонять представления на их основе). Например, решение бедного человека состояло бы в том, чтобы просто сканировать каждый файл для его объявления пакета и его операторов импорта, а затем иметь некоторую эвристику для обнаружения плохой зависимости.
Другим подходом является объединение различных компонентов в отдельные JAR и загрузка их с помощью настраиваемого ClassLoader, что позволит вам предотвратить незаконный доступ с использованием отражения (что в противном случае могло бы обойти любую структуру программы).
В дополнение к автоматизированным методам ручные подходы также имеют свою ценность. Ручные подходы включают регулярные проверки кода и политики, которые должны соблюдаться во время этих обзоров кода и аудита.
Короче говоря, нет ни одного правильного ответа. Необходимо использовать несколько разных подходов в зависимости от того, насколько важно это разделение.
Просто задал тот же вопрос Майклу Аарону Сафяну, но, на ваш взгляд, эти дорогие/привлекательные подходы реалистичны для обслуживания кода сакса? или программист дисциплины путь? – flakes
Замечания программиста достаточно, если вас беспокоит только ремонтопригодность кода. ИМО. –