Каждый маленький программист, можно сказать, с молоком матери впитывает идею постоянного сокрытия данных, и, если в методах класса с модификатором public ему приходится мириться, то вот поля обязательно должны быть private или уж на крайняк protected! Со временем это переходит в ритуал, благодаря которому для простого доступа или изменения полей класса надо писать еще дополнительный код стандартных геттеров/сеттеров. Веселуха начинается при написании какого-либо java-класса PODJO типа сущностей для доступа к таблицам в БД с десятком-другим полей в каждой, или action'ов из фрэймворка Struts2. Тогда программа обрастает прям километрами кода. Честно, не понимаю, зачем для простого получения/изменения значения поля обязательно нужны некие костыли? Допускаю необходимость инкапсуляции - в разумных пределах, но писать код типа

и потом обращаться к х и у через point.getX() / point.setX(х) считаю явным излишеством. В этом случае гораздо проще использовать для полей модификатор public и обращаться к ним напрямую:

 В С#, на сколько я знаю, для этого есть сахарные костыли, называемые свойствами, которые имитируют прямой доступ к переменной: point.х = х. Для этого класс Point надо оформить так:

Данный код выглядит значительно короче, чем в java, но по поведению также практически ничем не отличается от кода 

Видимо, java-сообщество просекло фишку и создало библиотеку lombok, с помощью которой можно сократить код до

Имхо, все эти телодвижения происходят из-за проблемы, которую сами себе и создали. А насколько было бы проще жить, если не возводить инкапсуляцию данных в священную догму!

А что если потом придётся делать некие проверки при установке или передаче этих значений? Весь код, который использует данные переменные придётся переписывать.

Имхо, нихрена это не костыли. Для меня это очень большой плюс в сравнении с плюсами, к примеру, на которых я пишу большую часть кода.

  А я не парюсь при использовании тривиальных полей, пихаю их в паблик и пошло оно все лесом. На крайняк всегда есть рефракторниг и ctr+shift+f .

И в чём же плюс?

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

Согласен, это плюс. Но, к примеру, в классах-сущностях проверки можно осуществлять и при помощи аннотаций к полям:

Pawl, а чем не устраивает то объяснение, которое дается в любом пособии для начинающего программиста?  По мере развития проекта может возникнуть ряд ситуаций, как то: 
1. При тестировании может выяснится, что некоторые значения переданные полю, приводят к некорректной работе класса. В данном случае может возникнуть необходимость либо корректировать налету полученное значение либо отклонять изменение значения.
2. Существует вероятность того, что в процессе развития проекта может возникнуть необходимость уведомлять заинтересованные стороны о том, что значение поля изменилось, либо кто-то пытается его изменить. 
3. Для оптимизации работы класса может понадобиться, к примеру, ленивая инициализация значения (то есть объект создается при первом обращении к свойству, в противном случае не создается вообще).

Во всех этих случаях прямое обращение к полю может привести к необходимости переписывать туеву хучу кода.


Не имитируют. То, что ты привел - это т.н. автоматически реализуемое свойство. Его объявление мало чем отличается от объявления поля, но фактически компилятор создает обычные акцессоры свойства со стандартным кодом. Для них всегда можно описать реализацию вручную с тем же успехом. Надо сказать, что автоматическая реализация - сама по себе очень крутая штука и сильно сокращает количество кода. Но, в то же время, даже когда ее не было (в шарпе она появилась в 2005-м, а в бейсике в  2008-м), свойства все равно отчасти решали описанную тобой проблему. Дело в том, что в языках, где есть свойства, инкапсуляция доступа к полям  в принципе не так критична. Несмотря на то, что во всех учебниках пишут о том, что публичные поля - зло, тем не мене, в языках со свойствами поле почти всегда можно совершенно безболезненно заменить свойством, если такая необходимость возникла(есть пара  случаев исключения, но в основном они не критичны).

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

Ну так вы, можно сказать, сами и ответили на свой вопрос:

Т. е. Можно написать так:

и при необходимости заменить поля свойствами с необходимыми проверками. При этом доступ из других классов как был point.х, так и останется point.х, т. е. их модифицировать не понадобится.

Это сообщение отредактировал(а) Pawl - 30.5.2014, 11:18

Я не задавал вопросов, а попытался ответить на твой.

Ну так на C# можно. Это не будет работать при обращении к свойствам через рефлексию, а так же, если код вызывается из проекта написанного на языке, в котором нет свойств. Например был в семействе дотнет-языков такой язык как J# (на заре развития технологии с его помощью пытались привлечь ява-программистов). В нем свойств нет, и обращаться приходится к методам-акцессорам непосредственно. Но такие языки мало распространены, так что большой проблемы в этом нет. А так вообще да, свойства в принципе для этого и существуют. Когда я интересовался явой, то одной из причин, по которой я оставил эти попытки было именно отсутствие свойств, поскольку к хорошему быстро привыкаешь.

Думаю теперь, когда Оракл обязался выпускать по новой версии java не  реже, чем раз в 2 года, свойства в ней тоже появятся и причины для принудительной инкапсуляции со временем исчезнут  - с учетом того, что свойства во многих языках программирования уже реализованы, а в с++ тоже могут появиться. По крайней мере, потребность в них есть, т. к. люди извращаются, чтобы реализовать их самостоятельно.

Перекомпиляция все же потребуется.



Метода акцессоры можно мокать, а вот доступ к полям фиг замокаешь.

  Pawl привел тривиальный случай и я, собственно, в этом контексте комментировал. То что ты описал никак нельзя назвать тривиальным случаем. Это только быдло кодеры пишут класс и не представляют себе как его потом будут использовать. При конструировании программы от простого к сложному заранее понятно, что точка это пассивный объект из 2-3 полей и из нее никто не будет строить в последствии объект с виртуальными функциями и т.д. В С++ есть даже такое понятие как POD тип Plain Old Data, т.е. тип, который устроен так как описан. На самом деле, очень здорово, когда простые вещи устроены простым образом, это делает код прозрачным. Программист, который читает такой код не вынужден каждый раз обращаться в реализации функции GetX чтобы убедиться в том, что ее реализация тривиальна. Экономиться куча времени на чтении и куча времени на компиляции.

Автоматически реализуемые свойства вообще никаких проблем с разрастанием кода не создают, так что лучше уж их использовать, если они есть. Да и не факт, что свойства появятся. Насколько мне известно, Сан не добавлял новые фичи в язык потому, что считали все это веяниями моды и не  хотели засорять ими язык. Что будет делать Оракл - неизвестно, хотя, вроде кое-что уже сделал полезное(лямбды замыкания и прочее).


Даже в яваскрипте есть уже  

Да. Но она обычно и так выполняется время от времени. Хотя согласен, что лучше такими заменами не злоупотреблять.


Он вроде там приводил пример с сущностями для доступа к объектам датабазы. Ну так такие классы обычно генерируются автоматически, а писать их руками - чистой воды извращение  

Я не об этом написал. Я написал о том, что код, который пишешь ты, возможно будут использовать другие разработчики и просить их каждый раз, чтобы они рефакторили свой код из-за того, что ты поленился описать акцессоры можно до поры до времени, но если делать это постоянно, то тебе могут устроить "тёмную"  
 Но ты ведь в данном случае написал, что таки возникают проблемы с этим и порой приходится рефакторить. Так что простота не гарантирует отсутствия проблем в будущем.
А вообще, при наличии нормальных инструментов, тривиальный код генерируется автоматически. Думаю, что для любой ява-иде такие инструменты, которые ну по крайней мере код акцессоров генерят, найти вполне можно. Поэтому проблемы в этом не вижу.

   Простые классы просто рефракторятся, но этого как правило и не требуется. 

  Тебе наверное редко приходиться читать чужой код без комментов. Иногда берешь чужую прогу и хочется убить автора. Там где можно написать решение в 100 строк, обнаруживаешь 1500 вот таких вот пустых строк и вдобавок непонятные иерархии, наследования виртуальные функции и т.д. Раздувают общее решение для узкой задачи.
  Программист не должен быть заложником ООП. ООП нужен там где он нужен, а там где не нужен, то нужно писать простой компактный читабельный код, который не нуждается в документировании и даже комментариях.


  У меня нет проблем со скоростью печати. Пока обдумываешь решение хватает времени не то что гетеры с сетерами налепить руками, а еще сделать выравнивания, отступы пробелы и прочий марафет облегчающий восприятие кода.


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

Да, но как я уже написал, делать это, возможно, придется не только тебе одному. А если все будут поступать так же, то работенки прибавится всем и немало.

Я тут вообще ни при чем. В случае со мной публичное поле объявляется такА публичное (по умолчанию) свойство такИ мне сложно представить аргументы в пользу того, чтобы отдать предпочтение первому варианту, но если они у тебя есть, то я весь - внимание.
Согласен полностью, только не знаю, при чем тут ООП. Обеспечивать доступ к данным из одного места программистов научила практика. Для случаев, когда можно быть уверенным, что никакое изменение порядка доступа к полю не потребуется, я ничего против паблик-полей не имею. Мало того, в литературе мне встречалось утверждение, что, например, в структурах паблик-поля - вообще обычное дело. В принципе догматизм - это всегда плохо, всегда надо не только знать как что сделать, но и понимать почему. Тем не менее иметь в виду возможное(но не очевидное в данный момент) изменение условий - совсем не лишняя предосторожность ибо ситуации такие не редки.


А у меня есть, да и отступы руками делать не привык, поскольку иде с этим прекрасно справляется. И вообще, чем меньше кнопок приходится жать - тем лучше  

Я писал о коде, который используют другие. Вот ты при необходимости взял да и заменил публичное поле акцессорами. Отрефакторил все те места, где ты к этому полю обращался и вроде все нормально. Только проблема в том, что если и у других разработчиков имеется код, где они обращались к этому же полю, то и им придется в каждой такой ситуации делать то же самое. Я говорил только об этом и тут не имеет ровны счетом никакого значения степень тривиальности кода. А если каждый начнет делать так же как и ты, то это может обратиться в серьезную проблему.