Проблема. В C++ у класса можно сделать классы "друзей". Friend-классы видеть private и protected поля из класса.

В Java protected поля видны на уровне пакета ((( Что очень не удобно. Полный отстой в проекте получается. Есть core-классы. Которые содержать основные обрабатываемые сущности:

com.my.core.*

Делать все их поля public не особо хочется. Т.к. есть служебные поля, нужные только во время расчетов. Есть несколько пакетов, которые обеспечивают базовые алгоритмы над этими class'ами. Например пакет:

com.my.raiting.*

Который по достаточно сложным критериям вычисляет разные рейтинги + __куча__ классов передачи параметров туда-обратно нужные для расчета рейтинга.

Проблема в том, что при расчете хочется иметь доступ к внутренним (protected) полям класса для ускорения работы. А нельзя... ((( Приходится городить фигню. Основные алгоритмы расчета складывать в com.my.core, а все служебные классы держать в com.my.raiting. В общем, в проекте помойка получается ((((

Таких расчетов над над базовыми классами несколько и очень достает, что их нельзя как в C++ объявить просто friend классом .

Как как с таким живет? Просто складываете в тот же пакет или как-то по другому решаете проблему?

maytonДружище ты чет напутал.

В Java protected поля видны на уровне пакета

Protected scope и package scope это разные вещи. Мне кажется я твою мысль
уже начал улавливать дальше по тексту, но лучше лишний раз переспросить.
Мне казалось одно и то же (((

Пойду погуглю.... )))

Погуглил. Толку не много. (((

protected видно или в том же package или в subclass (((

Я subclass делать не хочу. Просто отдельный класс-обработчик. В C++ это легко решается с помощью friend.

chpashaимхо для собственного кода проблема надуманна. если пару лишних свойств!!! будут public, небо на землю от этого не упадет. мы же про геттеры говорим да?
Я не спорю, что в чем-то надуманная.

Просто когда "собственного кода" > 800 Кб, уже становится сильно не удобно по пакетам лазать ((( Уже сам забываю, как классы называются и кто что делает )))

Наверное правильнее решить через Interface и наплодить get/set'ов... Один интерфейс - доступ к внешним полям объектов (сделано), другой интерфейс - получение внутренних/для расчетов.

Для себе уже понял, что нужно будет делать два интерфейса. Минимальный для GUI. Максимальный с внутренними структурами для расчетов.

Просто разрабатывается прототип. Т.ч. get'ы/set'ы и интерфейсы делаю по самому минимуму. Все равно перед продакшеном все тотально рефакторится будет.

p.s. начальство вообще закладывает, что весь код выкинуть, нанять программистов, написать заново. Типа "код для продакшена" != "код для прототипа" ))) Продакшен код должен быть какой-то особый )))

Alexey Tomin... Если не увлекаться интерфейсами (inliine работает если у метода есть не более 2х реализаций).
Что значит "не более 2х реализаций" ?