Геттер и сеттер, срабатывающий при прямом обращении к полю

Вот нельзя ли в java сделать
чтобы инструкции вида

b = foo.a;
foo.a = c;

автоматически вызывали геттер и сеттер соответственно

Насколько я знаю, нельзя. И не нужно.

Смысл?

тебе нужна Scala

В Groovy такое есть.

Зачем нужно? Просто сама работа с геттером и сеттером в явном виде многословна, конечно, несмертельно, но если можно сократить, то почему бы нет,но насколько я понимаю это противоречит идеологии java, а scala в очереди )

В Delphi можно :-P

беглый гуглинг приводит, например, сюда: http://stackoverflow.com/questions/1264674/java-property-change-listeners

то есть, если ты добьёшься желаемого, твои объекты будут уже нифига не POJO, а с кучей (ненужного) фарша. Я бы геттеры с стеттерами подёргал, нежели так заморачиваться..

Знаю, но там много чего другого нельзя да и не кроссплатформенно)

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

На уровне языка нельзя. Можно перед загрузкой класса пройтись по его коду и заменить все инструкции чтения-записи поля на вызов соответствующих getter-ов/setter-ов. Но это ненужное усложнение.

можно еще через AOP сделать, но опять же...

Чтобы не определять геттеры/сеттеры, когда они не нужны. Избавляет от кучи бойлерплейта.

Фуу, это C# головного мозга. Срочно читать K&R и 2 раза установить-удалить вижуалстудию.

А в чем смысл? Геттеры и сеттеры нужны как раз для того, чтобы не перепутать и не записать поле там, где его нужно прочитать. Т.е. для того, чтобы явно вызывать геттеры и сеттеры. А твой подход ничем не отличается от прямого обращения к полю. Или я чего-то не понимаю?

ну раширьте область видимости полей до default, public и не пользуйте геттеры, если хотите писать меньше букав, ведь смысл в этом да? :)

Смысл геттера и сеттера я вижу в несколько ином:в него можно включить ограничения и проверки на то, что значение присваиваемое переменной соответствует ожидаемому. Хотя и защиту от случайной модификации сеттер и геттер может дать, не спорю, но мне кажется рассматривать сеттер и геттер в таком ключе это как излишняя защита «от дурака»

Э не, если б все так просто)

поддерживаю

у вас искаженное понятие геттера/сеттера, там не нужно логика.

Википедия вполне справедливо пишет:

Сеттер (Мутатор, англ. Mutator) — специальный метод, используемый в объектно-ориентированном программировании для того, чтобы присвоить какое-либо значение инкапсулированному полю, например, обработав при этом недопустимые присваивания.

Сложная логика, конечно , там не нужна, но сеттер в стиле this.a = val; выглядит лишней сущностью, так как он фактически ничего не делает, что с таким сеттером, что без него я могу совершенно невозбранно, например, в переменную с зарплатой зафигачить отрицательное значение.

Есть такая штука, как project lombok. Она частично решает такие проблемы, использование описано, например, на хабре (тут же не снимают скор за такие ссылки?).
С ним становится можно писать вот так:

public class GetterSetterExample {
    @Getter @Setter private int age = 10;
    @Setter(AccessLevel.PROTECTED) private String name;
    @Getter(lazy=true) private final Map<String, String> map = initMap();
}

C#
K&R

/0

это C# головного мозга
Фуу

Будто что-то плохое.

http://projectlombok.org/features/GetterSetter.html + плагин на идею.

опередил)

Я с дотнетом работаю. Да, это что-то - плохое.

Спасибо

там не нужна, но сеттер в стиле this.a = val; выглядит лишней сущностью

лол. synchronized, override, проверкі (в качестве багфіксов) ты потом куда пхать будеш?

Какую хероту могут напрідумывать только бы setX()/getX() не пісать.

Главная Проблема Жавы - там нет сахарку вроде autoreplace getX() -> FirstCharToLower(X).

возможно этот пломбок юзает undocumented features кастомной компіляціі = undefined behaviour.

Лол это тогда сообщение выше:

у вас искаженное понятие геттера/сеттера, там не нужно логика.

. Сеттер с логикой для контроля, поддержки присвоения понятен

когда ты поймёшь что логика там нужна - будет уже поздно. Цэ-подобные структуры логично делать только private package or private.

Понятное дело, что логика там может появиться несразу

https://github.com/dzidzitop/ant_modular/blob/master/src/java/afc/ant/modular...

private static class Context - вот это для меня практически единственный случай когда set/get не нужен.

А вот set/get «без логики»: https://github.com/dzidzitop/ant_modular/blob/master/src/java/afc/ant/modular...

Там просто кастомный процессор аннотаций.

On javac (and maven, ant, and other build tools)
Include lombok.jar on the classpath as you compile. That's all there is to it!

Вот это позволяет усомниться. Там явно переподкладывается отпроцешеный код на место старого и потом компилится через javac. Ну или хз что там.

* <p>The tool environment is not required to support annotation * processors that access environmental resources, either {@linkplain * RoundEnvironment per round} or {@linkplain ProcessingEnvironment * cross-round}, in a multi-threaded fashion.

нет, вот это (что-то есчё можно найті явно):

 * <p> In general, processors must not knowingly attempt to overwrite
 * existing files that were not generated by some processor.  A {@code
 * Filer} may reject attempts to open a file corresponding to an
 * existing type, like {@code java.lang.Object}.  Likewise, the
 * invoker of the annotation processing tool must not knowingly
 * configure the tool such that the discovered processors will attempt
 * to overwrite existing files that were not generated.

Ага, он на этапе компиляции фигачит кастомное AST. То есть он встряет на том же этапе, что и процессоры аннотаций, но занимается модификацией АСТ.

А как это может проявиться в UB?

Пиши по-русски.

Пиши по-русски.
встряет

бывает

А как это может проявиться в UB?

• IOException: unable to open file
• Еслі делать replace .java то компілятор может не увідеть обновлённый код

  Что там юзается - хз, но просто как кодогенератор оно бы работало прозрачней.

в php можно :-p

в жаве - нет. </thread> </java>

Что бывает?

компілятор

ЧЗХ?

Логику лучше не хранить в бинах. Это, как минимум, не красиво. Пересмотрите архитектуру.

Да не какие бины? Самые обыкновенные классы у приложения формируются пока, до бинов и прочих наворотов дело вряд ли дойдет

Не делай в сеттерах проверки, для этого есть java validation (если javaee) и контракты.

Алсо, то, что ты в ОП описал, не нужно — если не хочешь использовать сеттеры/геттеры, просто не пиши их. Но лучше пиши и используй. :-)

Самое главное же не написал :)
Проверки эти делай не в pojo, а в бизнес логике и где-то около неё.

Вот вы всё спорите о геттерах/сеттерах, лучше посмотрите, как сам язык меняется: http://habrahabr.ru/post/203026/ (прости, господи, за ссылку на сами-знаете-куда).

use Ruby