видимость пакета

Как сказал Ростислав Матл, это полезно, когда вы хотите сделать что-то, что не является частью интерфейса вашего пакета.

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

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

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

Это пример использования некоторого кода:

У нас есть свой интерфейс:

public interface UsefulService {
    Collection<DataThings> getThings(Identifier id);
}

...и наша конкретная реализация:

public class JdbcUsefulServiceImpl implements UsefulService {

     //We can break the code for the mapping out into its own class
    private Mapper mapper;

    @Override
    public Collection<DataThings> getThings(Identifier id){
        DatabaseQueryResult queryResult = //Code to hit a database and return objects from that domain model
        Collection<DataThings> result = mapper.mapFromDatabaseToServiceDomain(queryResult);
        return result;
    }
}

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

class Mapper {
    Collection<DataThings> mapFromDatabaseToServiceDomain(DatabaseQueryResult queryResult){
        //magic to map objects goes here
    }
}

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

Насколько я понимаю, доступ к пакету/по умолчанию предназначен для внутренних компонентов пакета, т. е. классов, которые не формируют интерфейс пакета, т. е. классов, которые не следует использовать вне пакета.