Организация класса Java

Question

Чтение этого java-текста, и авторы советуют думать о пакете org, оставляя только классы, которые действительно должны быть открыты для остального мира как общедоступные.

Я думаю, что я получаю точку, что немного обнажая то, что не требуется позволяет изменять вещи позже, не нарушая код клиента - но я не могу придумать пример -

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

Любые примеры или рекомендации будут оценены!

Answer 1

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

Предположим, что вы делаете метод общедоступным, а кто-то его использует. Затем вы понимаете, что вам нужно изменить метод. Теперь у вас есть два варианта:

1. Координаты с этим клиентом, чтобы внести изменения.
2. Разбить клиента.

Очевидно, что вы хотите избежать # 2, если это возможно.

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

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

Пример. Say Я пишу библиотеку управления заказами электронной коммерции, и я пишу метод

public double computeTax(double price) { ... } 

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

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

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

public Currency computeTax(Currency price) { ... } 

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

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

Answer 2

Вот принцип, которым я придерживаюсь в основном. Сделайте видимость класса или методов или даже параметров до минимально возможной видимости. Фасадная схема является хорошей практикой для раскрытия коллективной функциональности классов. Другая хорошая практика - использовать объект в качестве типа параметра для публичного API, а затем преобразовать его внутренне в желаемый тип, таким образом, вы можете избежать потенциального разрыва кода.