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


Вопрос: как это может работать?

Добавлено через 8 минут и 47 секунд
М-да... прошу прощения, я действительно ничего не понимаю в модификаторах доступа.
Нашёл тут в довольно старенькой книжке (точнее, в заметках, сделанных по книжке), что

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

P.S. Просьба к модераторам: не удаляйте тему. Думаю, найдутся и другие "ничего не смыслящие". 

хм... очень интересно, не знал таких подробностей, поэтому порылся на java.sun.com и вот что нашел
modifiers

Давайте не будем томить народ, там речено:

Лично мне такое не нравится - Delphi вспоминается...

Это сообщение отредактировал(а) Ulysses4j - 26.6.2007, 06:06

 
Собственно это как бы прописная истина ;)

И еще: если сабж без модификатора, то ведет он себя именно так, как ты хочешь, чтобы вел себя protected ;)

+1

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

Хотите сказать, что package-private и protected это одно и то же? Сомневаюсь. Если подкласс данного класса находится в другом пакете, то protected-члены базового ему будут видны, а package-private базового - нет.

Не скажи. Судя по информации на офсайте поле без модификатора ведёт себя не так, как protected в том же с++. Смотрим в табличку и видим, что такое поле видно в пределах пакета, но не будет видимым классу-потомку, который лежит в другом пакете. "Стандартный" же protected наоборот подразумевает видимость потомкам, а не пакету.

Вся эта котовасия происходит от желания _четко_ разделить иерархию доступа, то есть, чтобы одна полностью включала другой.
public
protected
package
private

И вследствие этого к пакетам следует относиться внимательнее, помня, что это не только средство модульной декомпозиции, но и средство инкапсуляции.

Это сообщение отредактировал(а) fixxer - 26.6.2007, 09:24

В Java он ведет себя именно так как описано выше, с самой первой версии. О причинах fixxer уже написал.

М-да... что-то я всё же заглючил. protected ведёт себя почти так, как я и понимал. Так же как и no modifier.
Единственный момент, которого я не знал - это, что protected виден и всем внутри пакета.

В книжке "Секреты программирования для Internet для Java" еще по jre 1.0 было написано, что тогда во всяком случае был еще один модификатор. Цитата с книжки:

Его убрали скорее всего потому что разработчикам захотелось, чтобы было по одному модификатору доступа. А про protected там написано:

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

Это сообщение отредактировал(а) progdog - 30.6.2007, 11:59

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

Это сообщение отредактировал(а) EvgenZ - 30.6.2007, 09:32

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

Я вот так тестил:



Это сообщение отредактировал(а) progdog - 30.6.2007, 13:44

Там ошибка в том, что нет импорта для Parent-а. А в остальном код полностью корректный.

Ну да, точно  Перепечатал из исходника, про импорт забыл.

Но это все равно сути дела не меняет.

Какой сути? Если ты про то, что 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?

Я такое уже разок встретил. Долгой работы с этой командой у меня не вышло почему-то. 

Ну так он нам и приводил примеры из жизни. Работает он на Чикагской бирже, цена ошибки - сотни тысяч, миллионы денег. Естественно, при такой потере нужен козел отпущения. Им будет тот, у кого код сработал неправильно. Если кто то изменит твой объект без всех предусмотренных проверок, то может сложится все что угодно. Виноват будет скорее всего тот кто неправильно туда записал, понятен пень. Но ведь можно и под раздачу попасть и на пару вылететь. Собственно, это не есть недоверие к работе других, это ответственность за свой участок. 
По моему так.

А отдел тестирования? Если они приняли продукт и он попал в production, то все вопросы в такой ситуации только к ним.