Какой сути? Если ты про то, что Eclipse показывает для данного кода ошибку, то выкини его. Потому как или он поддерживает язык или нафиг он вообще сдался.
Только я думаю, это ты что-то перепутал, т.к. не может Eclipse давать ошибку в таком тривиальном случае.

progdog привёл всё же не тот пример, на котором получил ошибку. Вот если бы в классе Child метод test() был бы таким

то была бы ошибка - класс-наследник в другом пакете может вызывать protected-метод только для себя, для других объектов Child или наследников Child. 


Это сообщение отредактировал(а) w1nd - 1.7.2007, 04:12

Ну это правильное поведение, я даже видел объяснение почему так.

Извиняюсь,  забыл сохранить parent   , когда проверял

Мой преподаватель настоятельно рекомендовал не пользоваться protected в подаваляющем большинстве случаев. Либо private, либо public. 

"Если Вы создаете новый пакет и наследуете класс из другого пакета, то единственные члены, к которым Вы имеете доступ, это публичные члены в исходном пакете. (Конечно, если наследование происходит в том же самом пакете, Вы имеете нормальный пакетный доступ для всех “дружественных” членов.) Но иногда, создатель базового класса хочет разрешить доступ к конкретному члену только для наследуемого класса, но не всему миру в целом. Именно это делает protected".

Модификатор доступа без имени называют дружественным. "...дружественные элементы имеют доступ на уровне пакета..."
...все другие классы в том же пакете имеют доступ к дружественным членам, но для классов за пределами этого пакета, члены являются приватными (private).

Цитаты взяты из Эккель "Думаем на Java 2". 

Вывод: дружественный и защищенный модификаторы похожие, но не идентичные.

niasilil, а почему?

Он работает на бирже, руководит QA отделом и смотрит на все со своей колокольни. То что должно быть скрыто - все private, это понятно. Никаких полумер. А то что открыто, пусть даже с дефолтным или protected модификатором, это любой другой человек из команды может использовать (и изменить) в другом месте программы. Значит отвечать кому? Правильно, тебе, потому что это твой кусок кода. Он нам говорил rule of thumb - если пишешь protected, то подумай еще раз, все шансы что ты на неправильном пути. 

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

Не говоря уже о переопределяемых методах в наследниках - вообщем-то protected достаточно удобная идея.

Ну не все так плохо, рассматривал   Только опять же pros and cons, encapsulation, и т.д. ... Вместе с хорошим всегда идет и плохое, доступ же не только наследники получают в этом случае. В большинстве случает getters and setters лучше (уж там мы точно постараемся все проверки сделать, чтоб не дай бог какой придурок ... ну и тд)  
Вобщем, просто пожелаение - подумать.

Добавлено через 2 минуты и 49 секунд

Да, конечно, никто и не спорит. 

Многолетний опыт говорит о том, что как ни делай проверки, а всё равно найдётся тот самый "придурок", который сумеет-таки это дело завалить. Естественно, это не умаляет достоинств проверок как таковых. Просто, кроме проверок, надо и саму структуру объектов делать хорошей, в чём protected всё же больше помогает, чем мешает.
А вашему преподавателю я могу сказать лишь то, что у него малость не всё в порядке с мозгом. Его позиция похожа на позицию одной преподавательницы в ВУЗе, где я учился. Она считала, что GOTO - вещь опасная и ненужная, а потому его нельзя использовать. Все, кто использовали GOTO в программе, имели проблемы при сдаче задания. Я согласен, что злоупотреблять им не стоит, но бывают в жизни ситуации, когда использовать GOTO явно предпочтительнее, чем пытаться заменить его иными конструкциями. То же самое и с protected в жабе. Ваше право не использовать что-либо, но вы не сможете доказать, что это объективно обоснованно во всём спектре задач.

Мы перетираем воду в ступе, обсуждаем очевидные вещи. Причем даже не противоречим друг другу.  
Ваш пример про GOTO как нельзя лучше описывает ситуацию. Именно эту мысль "что злоупотреблять не стоит" я и пытался донести. Добавлю что если цена ошибки велика, то нужно рассматривать все возможные гипотетические неприятности. 

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


Все в любом случае не рассмотришь, а посему лично я предпочитаю чистую и ясную структуру объектов, а не возможную защищённость кода на основе геттеров/сеттеров с не меньшей возможностью потерять читабельность из-за неочевидных действий внутри упомянутых методов.
С другой стороны, если сам объект предполагает наличие защиты при установке получении значения поля, то, естественно, эти методы просто обязательны.
Правда, такая защита для protected- и private- полей нужна, по-моему, нечасто.

А потом найдется умник которому это надо позарез, и он полезет через рефлексию  
Я не понимаю как можно так работать в команде, что приходится защищаться от своих-же коллег  
Да и при чем тут ты, это же его код привел к ошибке. Ведь если я запишу неправильные данные в файл, мне что винить разработчиков JDK, потому что они не добавили нужные проверки в FileOutputStream?