Чи корисний обсяг рівня пакету Java?

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

Моє головне питання завжди здається, що речі, якими я хочу обмежити сферу дії, ніколи не знаходяться в одному пакеті. У принципі вони можуть бути пов’язані між собою, але логічний поділ даних всередині програми містить їх як окремі дочірні пакети більшого пакету.

Наприклад, у мене може бути модель Місії, і я хочу використовувати лише інші інструменти Місії, як-от моя місія Сервіси, використовувати деякі методи. Однак я закінчую Missions.models і Missions.services як мої пакети, тому MissionModel і MissionService не є однаковою сферою пакету. Ніколи не здається, що існує ситуація, коли пакети належним чином містять речі, для яких я хотів би мати підвищені дозволи, не включаючи також численні речі, я не хочу мати цих дозволів; і рідко я відчуваю перевагу методу визначення обсягу пакунків, що виправдовує зміну моєї архітектури проекту, щоб розмістити все в одному пакеті. Часто або аспекти, або якась інверсія управління виявляються кращим підходом до будь-якої проблеми, яку я коротко розглянув, як визначати обсяг пакету.

Мені цікавіше, а це, як правило, вважається справжнім для всіх розробників Java, або це просто обробка моєї роботи. Чи багато використовується в реальному світі? Чи багато випадків, коли це вважається хорошою формою для використання, або це сприймається здебільшого як спадкова поведінка, яку рідко можна використовувати в сучасному розвитку?

Я нічого не запитую про те, чому приватна область пакету за замовчуванням, я запитую, коли його слід використовувати незалежно від значень за замовчуванням. Більшість дискусій щодо того, чому це за замовчуванням, насправді не вступають, коли обсяг пакету насправді корисний, замість цього просто аргументується, чому інші два широко використовувані області застосування не повинні бути за замовчуванням, тому пакет виграє в процесі усунення. Крім того, моє запитання стосується сучасного стану розвитку. Зокрема, чи розробили ми до того часу, коли інші інструменти та парадигми роблять обсяг пакету менш корисним, тоді він був ще тоді, коли рішення зробити його за замовчуванням мало сенс.

Протягом усього java.util.*пакету є випадки, коли код пишеться із захистом рівня пакету. Наприклад, цей біт java.util.String- конструктор на Java 6 :

// Package private constructor which shares value array for speed.
String(int offset, int count, char value[]) {
    this.value = value;
    this.offset = offset;
    this.count = count;
}

або це метод getChars :

/** Copy characters from this string into dst starting at dstBegin. 
    This method doesn't perform any range checking. */
void getChars(char dst[], int dstBegin) {
    System.arraycopy(value, offset, dst, dstBegin, count);
}

Причиною цього є те, що дизайнери коду (і java.util.*їх можна вважати досить великою бібліотекою) хотіли можливість мати більш швидку продуктивність за рахунок втрати різної безпеки (перевірка діапазону масивів, прямий доступ до інших полів що передбачає реалізацію, а не інтерфейс, "небезпечний" доступ до частин класу, які в іншому випадку вважаються незмінними за допомогою публічних методів).

Обмежуючи доступ до цих методів і полів лише іншими класами в java.utilпакеті, це дозволяє тісніше з'єднатись між ними, але також уникає піддавати ці деталі реалізації світові.

Якщо ви працюєте над додатком і не потрібно турбуватися про інших користувачів, захист рівня пакунків - це не те, про що потрібно турбуватися. Окрім різних аспектів чистоти дизайну, ви можете зробити все publicі бути в порядку з цим.

Однак якщо ви працюєте над бібліотекою, яку повинні використовувати інші (або хочете уникнути занадто сильного заплутування ваших класів для подальшого рефакторингу), вам слід використовувати найсуворіший рівень захисту, який вам надають для ваших потреб. Часто це означає private. Однак іноді вам потрібно розкрити деталі реалізації іншим класам у тому ж пакеті, щоб уникнути повторення або трохи полегшити фактичну реалізацію за рахунок з'єднання двох класів та їх реалізації. Таким чином, захист рівня пакету.

Іноді я збільшую видимість приватних чи захищених методів упаковки, щоб дозволити тесту джуніту отримати доступ до деяких деталей реалізації, до яких не можна звертатися ззовні.

Оскільки junit-test має той самий пакет, що й тест-предмет, він може отримати доступ до цих деталей реалізації

приклад

  public class MyClass {
    public MyClass() {
        this(new MyDependency());
    }

    /* package level to allow junit-tests to insert mock/fake implementations */ 
    MyClass(IDependency someDepenency) {...}
  }

Дискусійним є те, чи це «добре» використання чи ні, але це прагматично

Це не все так корисно, особливо як за замовчуванням, у світі, де люди, як правило, використовують пунктирні назви пакунків так, як ніби вони були підпакетами. Оскільки у Java немає такого поняття, як підпакет, тому xyinternals не має більше доступу до xy, ніж це стосується ab Імена пакетів є однаковими або різними, часткова відповідність не відрізняється від того, що вони не мають нічого спільного.

Я здогадуюсь, що оригінальні розробники ніколи не сподівались, що ця конвенція буде використана, і хотіли зробити прості речі без додавання складності ієрархічних пакетів стилю Ada.

Java 9 - це на зразок вирішення цього питання, оскільки ви можете помістити декілька пакунків у модуль та експортувати лише деякі. Але це зробить обсяг пакету ще більш зайвим.

В ідеальному світі вони змінять область за замовчуванням на "область модуля, якщо такий модуль містить, інакше область пакету". Потім ви можете використовувати його для спільного використання в модулі, що дозволяє рефакторинг, не порушуючи експортовані інтерфейси. Але, можливо, є якась тонкість, чому це порушить зворотну сумісність або інакше буде поганим.

Тип зчеплення ваших описує це на самому ділі не кращий приклад того , де ви будете використовувати для доступу до пакету. Пакет зручний для створення компонентів, модулів, які взаємозамінні в інтерфейсі.

Ось приблизний приклад сценарію. Припустимо, ваш код був реорганізований так, щоб він був довше функціональної згуртованості та компонентності. Можливо, 3 банки, як:

**MissionManager.jar** - an application which uses the Java Service Provider Interface to load some implementation of missions, possible provided by a 3rd party vendor.

**missions-api.jar** - All interfaces, for services and model
    com...missions
        MissionBuilder.java   - has a createMission method
        Mission.java - interface for a mission domain object
    com...missions.strategy
        ... interfaces that attach strategies to missions ...
    com...missions.reports
        .... interfaces todo with mission reports ....

   **MCo-missionizer-5000.jar** -  provides MCo's Missionizer 5000 brand mission implementation.
       com...missions.mco
                  Mission5000.java - implements the Mission interface.
       com...missions.strategy.mco
              ... strategy stuff etc ...

Використовуючи рівень пакету в Mission5000.java, ви можете впевнитись, що жоден інший пакет або компонент, такий як MissionManager, не може зв'язати пару з реалізацією місії. Тобто лише "третя сторона", надана складовою "M co", фактично створює там власну спеціальну фірмову реалізацію Місії. Менеджер місій повинен викликати MissionBuiler.createMission (...) та використовувати визначений інтерфейс.

Таким чином, якщо компонент реалізації Mission буде замінено, ми знаємо, що реалізатори MissionManager.jar не обійшли api і безпосередньо використали реалізацію MCo.

Отже, ми можемо замінити MCo-missionizer5000.jar конкуруючим продуктом. (Або, можливо, макет для тестування підрозділу Mission Manager)

І навпаки, MCo може виконати деяку кількість приховування своїх торгових таємниць місіонізатора.

(З цим пов’язано виконання ідей щодо нестабільності та абстрактності в компонентах.)

Оскільки обсяг пакету в Java не розроблений ієрархічно, це навряд чи корисно. Ми взагалі не використовуємо область пакунків і визначаємо всі класи як загальнодоступні.

Натомість ми використовуємо власні правила доступу, засновані на ієрархії пакунків та заздалегідь визначеними назвами пакетів.

Якщо вас цікавлять деталі google для "CODERU-Правил".