Как правильно использовать модификатор доступа Java при разработке библиотеки

Question

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

Я не совсем понимаю цель модификатора доступа к Java.

Проблема в том, что у меня есть классы ниже

• ClassA в упаковке org.mylibrary
• ClassB в упаковке org.mylibrary.internal

ClassA должен разрешать ClassB, поэтому ClassB должен быть общедоступным классом.

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

Я думаю о перемещении ClassB в пакет org.mylibrary и сделать его закрытым классом.

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

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

Как мне это сделать? Как люди справляются с этой проблемой?

Answer 1

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

Answer 2

Мне кажется, я понимаю ваш вопрос, и ответ таков: до сих пор в Java этого не существует!

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

смотрите здесь

http://openide.netbeans.org/tutorial/api-design.html#design.less.friend

Answer 3

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

Вы имеете в виду, что файл Java выглядит грязно? Вы можете разделить внутренние классы в другом файле .java.

ClassA.java

package org.application;

public class ClassA {
}

Internal.java

package org.application;

class ClassB {
}

class SomeOtherInternalClass {
}

Надеюсь, это поможет.

Answer 4

Предполагается, что ClassB - это тестовый пакет с юнит-тестами:

Почему ClassB должен использовать это. Обычно тестовые классы используют обычные классы, а не наоборот.

Как правило, для тестовых классов рекомендуется помещать их в такой же пакет, что и обычные классы, но поддерживать файлы .java в параллельной иерархии каталогов (т. Е. У вас есть src / org / mycompany). /MyClass.java и test-src / org / mycompany / MyClassTest.java). Таким образом, для Java оба находятся в одном и том же пакете и могут обращаться друг к другу, а для выпусков сборки вы просто не компилируете тестовые классы (или даже не проверяете их) - таким образом, все красиво разделено.

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