Структура пакета Java

Question

Рекомендуется, чтобы интерфейсы / классы в пакетах более высокого уровня нормально зависели от интерфейсов / классов в пакетах более низкого уровня?

Например,

может com.company.core.SomeClass зависеть отcom.company.core.apackage.AnotherClass

Или зависимости должны течь по-другому?Я пытаюсь устранить циклы между пакетами.

Answer 1

Как правило, пользователь пакета может быть заинтересован в com.company.functionality.MainUse, который реализован с использованием com.company.functionality.implementationdetail.FiddleWithStuff, поэтому я бы сказал, что вы должны принять зависимости в этом направлении.

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

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

Answer 2

Они обычно текут в другую сторону.com.mycompany.myproduct.Widget является интерфейсом, а com.mycompany.myproduct.fancy.Button реализует его.

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

Сами пакеты - это просто папки, за исключением простых правил доступа к методам и полям.

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

Answer 3

Такие зависимости распространены даже в самом Java API.

Посмотрите: http://download.oracle.com/javase/6/docs/api/java/awt/image/renderable/package-use.html

Вы можете видеть, что классы в java.awt используют классы вjava.awt.image.renderable.

(ADDENDUM) Итог: оба направления используются на практике.Одно не обязательно, ИМХО, обязательно лучше другого.

Answer 4

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

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

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